RAT ATAF IS 17802 (Part 1) : 2021 
Indian Standard (Reaffirmed 2022) 


angee seurat sir Yararli 
eh feu STT 


GUT 1 stare 


Accessibility for the ICT Products 
and Services 


Part 1 Requirements 


ICS 35.240.80, 11.180 


© BIS 2021 


anda AM Sat 
BUREAU OF INDIAN STANDARDS 
HAR WH, 9 Te TH AMT, ay İde — 110002 


liz MANAK BHAVAN, 9 BAHADUR SHAH ZAFAR MARG 
NEW DELHI-110002 
www.bis.gov.in www.standardsbis.in 


December 2021 Price Group 16 


Active Assisted Living Sectional Committee, LITD 35 


FOREWORD 


This Indian Standard(Part 1) was adopted by the Bureau of Indian Standards, after the draft is finalized by the 
Active Assisted Living Sectional Committee, had been approved by the Electronics and Information Technology 
Division Council. 


This Indian Standard is published in two parts. The other part in this series is: 
Part 2 Determination of conformance 


The development of the Indian standard on Accessibility for ICT Products and Services was initiated by the 
Ministry of Electronics and Information Technology (MeitY) under the ‘Knowledge and Resource Centre for 
Accessibility in ICT (KAN) Project’ led by the Centre for Development of Advanced Computing (CDAC). During 
the preparation of this standard, several consultation meetings and discussions were held with a wide cross 
section of stakeholders including Ministry of Electronics and Information Technology (MeitY), Department of 
Empowerment of Persons with Disabilities (DEPwD), Ministry of Housing and Urban Affairs (MoHUA) and 
Department of Telecommunications (DoT). This Indian Standard is developed to provide a set of accessibility 
requirements that specify how to make content accessible, primarily for people with disabilities and also for all 
the end users. 


The present Indian Standard (Part 1) is the technical adoption of the European Standard EN 301 549 v 3.2.1 
“Accessibility requirements for ICT products and services” developed by CEN, CENELEC and ETSI. 
Modifications have been made to adapt it to India and are limited to referencing the relevant regulatory context 
(Rights of Persons with Disabilities Act, 2016) and the official languages of India. The technical coverage is 
otherwise identical. 


The requirements mentioned in this standard (Part 1) relating to the other departments under Government of India 
(GOI) are given in Annex A (informative). 


The idea on the further resources for cognitive accessibility is given in Annex D (Informative). 


Guidance to the users of this standard in providing the overview and also specifying the usage of this standard is 
given in Annex E (informative). 


The Composition of the panel, LITD 35/P1 and the sectional committee, LITD 35 responsible for the formulation 
of this standard is given at Annex F. 
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0 INTRODUCTION 


0.1 Background 


Driven by progress in technology and its increasing adoption in all walks of life, twenty-first century has been 
witnessing unparalleled opportunities for Information and Communication Technology (ICT) to create impact on 
the lives of citizens, economies and society. One dimension of the challenge for a country like India is its size and 
diversity, demanding scale and scope of technology interventions. Connecting and empowering over one hundred 
and thirty crore citizens through the growing use of ICT, with underlying innovation is progressively leading to 
transformation of India as a knowledge-based economy. ICT provides opportunities for faster economic growth, a 
better quality of life and greater inclusion and access. 


By building the digital edifice (infrastructure, services and digitalization) through a number of measures, a huge 
opportunity has been opened up for ICT to play a significant role in India’s economy and society. These range 
from provision of digital identity - Aadhaar; Digital payments supported by National Payment Corporation of 
India (NPC); Financial inclusion through JAM (Jan Dhan, Aadhar and Mobile) trinity; Increase in penetration of 
Broadband, Mobile and Internet (the number of mobile users and internet users in India are second in the world); 
setting up of lakhs of Common Service Centres (CSCs) to ensure citizen services delivery at the last mile; Health 
insurance services to 50 crore needy people through ‘Ayushman Bharat (PMJAY)’; Ayushman Bharat Digital 
Mission (ABDM); Telemedicine services through e-Sanjeevani; and delivery of digital e-Governance services — 
under an overall bouquet of policy, programs and promotional measures of ‘Digital India’ of the Government of 
India. In turn, the above measures are supported by initiatives of state governments and a domestic IT software 
products and services industry that is servicing the world, a fast-growing start-up ecosystem that is demonstrating 
vibrancy and a mobile manufacturing and electronics industry that is growing steadily. 


ICT is becoming an all-encompassing aspect for common people enabling them to perform duties effectively 
and productively on a daily basis. Driven by the rapid pace of technology and innovation, ICT based solutions 
are increasingly becoming digital and are rapidly being adopted by all key sectors-from banking and finance and 
e-commerce to education, health, agriculture, travel and more. Other national initiatives such as Smart Cities and Skill 
India are creating the momentum for wide sections of the population to adopt ICT solutions for greater efficiency, 
effectiveness, ease of life, and business velocity. It is in this context that it is very important that accessibility aspects 
are enabled by such a powerful ICT medium towards inclusive development. 


Accessibility in ICT is a measure of the extent to which a product or a service can be used by the Persons with 
Disabilities (PwDs) as effectively as it can be used by others. The concept of accessibility relates to the needs 
and abilities of diverse sections of PwDs and is expressed in degrees to which such needs are satisfied through 
ICT-from fully accessible to partially accessible or completely inaccessible for a specified user group. The more the 
number of people who can use an ICT product or service and the more tasks they can carry out effectively with it, 
the more is the ICT product or the service considered accessible. 


Increased accessibility brings benefits for users, producers, service providers, governments and society at large. 
Users benefit from being able to use the product or service more effectively and independently, enjoy inclusion 
in society and benefit from better employment prospects. Producers and service providers benefit from additional 
business, legal compliance, and customer diversity. It is in this context that certain legal rights have been provided 
for PwDs. Governments are able to ensure compliance with the Indian legal obligations along with the obligations 
undertaken by it in international conventions and treaties. 


Accessibility is being inclusive. By focusing on the needs and abilities of all users in all situations, it aims to include 
more of the users more of the time. Other terms for accessibility are Inclusive Design, Universal Design and Design 
for All. In times of increasing digitalization of economies and societies, Accessibility in ICT is a compelling need for 
pursuit of all daily activities by PwDs-from ability to conduct e-commerce and on-line banking to on-line education, 
on-line work, e-health, e-payment for utilities and daily needs, availing public facilities and services and more. ICT 
accessibility also serves the needs of senior citizens, temporarily disabled members and pregnant women. 


0.2 Rights of Persons with Disabilities Act, 2016 


India ratified the United Nations Convention on the Rights of Persons with Disabilities (CRPD) in 2007 and passed 
Rights of Persons with Disabilities act (RPwD act) in December 2016 which came into effect from 19th April 
2017. As per the RPwD Act 2016, twenty-one (21) types of disabilities have been recognized and listed under 
physical disabilities (locomotor disability, visual impairment, hearing impairment, speech and language disability), 
intellectual disabilities, mental behaviour, chronic neurological conditions, blood disorders and multiple disabilities. 
In terms of ‘International classification of Functioning, Disability and Health (ICF), the above disabilities can, in 
turn, be classified into nine. 
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In terms of duties and responsibilities of appropriate Governments, the Act clearly states that ‘The Central 
Government shall, in consultation with the Chief Commissioner, formulate rules for persons with disabilities 
laying down the standards of accessibility for the physical environment, transportation, information and 
communications, including appropriate technologies and systems, and other facilities and services provided to the 
public in urban and rural areas. 


The RPwD Acct further states under “Access to information and communication technology” — “the appropriate 
Government shall take measures to ensure that: 


a) all contents available in audio, print and electronic media are in accessible format; 


b) persons with disabilities have access to electronic media by providing audio description, sign 
language interpretation and close captioning; and 


c) electronic goods and equipment which are meant for everyday use are available in universal design.” 
RPwD Act, 2016 also presents a strategy for public procurement of Electronics and ICT services and solutions. 


Many initiatives, such as “Sugamya Bharat Abhiyan” (Accessible India Campaign), are being taken up by different 
Ministries and Departments of Government of India, State Governments, and other organizations for the PwDs. 


0.3 Accessibility Standard in Global Perspective 


While assistive devices based on ICT had come into being even in the twentieth century, the concept of “universal 
design” — mainstreaming of the concept in products and services to support better usability and accessibility for 
all have been gaining greater traction in the twenty-first century. Post emergence of Internet and World Wide 
Web (W3C) in early nineties, Web Accessibility Initiative (WAI) came into being by the dawn of the twenty-first 
century. With broad-based and global participation of experts, it has been looking at the technical means to address 
the needs of Web accessibility as also requirements in the form of Web Content Accessibility Guidelines (WCAG). 


Thus, WCAG 1.0 came in 1999 and WCAG 2.0 came in 2008 in response to further evolution of Web technology, 
access devices and multi-media content. WCAG 2.0 series has been updated in 2018 with WCAG 2.1. While the 
focus of WAI has been on Web, W3C/WAT had produced a Working Group Note by setting up WCAG2ICT Task 
Force to extend its accessibility guidelines beyond Web, to non-web areas of ICT. Accessibility guidelines and 
techniques are based on four core principles, namely, Perceivable, Operable, Understandable and Robust (POUR). 
These core principles address the accessibility requirements arising out of ageing, limited learning and temporary 
disabilities as well. 


Europe began to prepare its requirements standard on ICT accessibility from 2012 onwards through 
ETSI/CEN/CENELEC under EN 301 549 series and their thrust has also been similar with extended scope, but 
fully harmonized with WAI/WCAG. The EN 301 549 series represent a comprehensive and cohesive requirements 
standard, applicable for all categories of ICT, updated from time to time. 


USA has also updated its standard through latest release of Section 508 of Rehabilitation Act, 2019 and it is 
harmonized with both W3C/WAI/WCAG and EN 301 549 Standards as applicable at the time of approval of the 
revision. 


0.4 Objective of this Standard 


The RPwD Act, 2016 envisages laying down of the standards for accessibility for information and communications, 
including appropriate technologies and systems, and other facilities and services provided to the public in urban 
and rural areas. 


India has been laying down guidelines for accessibility of websites — and mobile apps, through inclusion of 
mandatory accessibility guidelines by National Informatics Centre (NIC) and Department of Administrative 
Reforms and Public Grievances (DARPG) for government sites by adoption of Guidelines for Indian Government 
Apps and Websites 1.0 (GIGW 1.0) in 2009 and GIGW 2.0 in 2019, in conformity with WAI/WCAG guidelines 
1.0 and 2.0 respectively. 


In response to RPwD Act, 2016, many sectors such as telecom, broadcasting, urban development, education, 
banking and other concerned ministries have also been undertaking stakeholder consultations for formulation 
afresh or updating of their accessibility requirements in respect of their sectoral applications of ICT. As a 
result, some of them have announced updated policies, standards and guidelines as in the case of Department 
of Telecommunications (DoT)/Telecom Regulatory Authority of India (TRAI), Ministry of Information and 
Broadcasting (MoI&B) (including in respect of Contents), Ministry of Urban Development and Ministry of 
Education. 
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In line with global trends on the development of a cohesive, consistent and cross-cutting standard on accessibility 
requirement for ICT products and services used in all sectors — as mentioned earlier, this standard consolidates 
and harmonizes current global and Indian standards and Indian user needs. In particular, it covers accessibility 
requirements for all web (covering text, audio, images and video) and mobile apps; closed and open system needs 
to operate without or with assistive technology devices; software; hardware-from desktops, laptops, mobiles and 
all else and including facilities; online (non-web) documents, contents and e-books; two-way voice including 
real-time text (RTT); ICT with video communications including TV with set-top box and remote control; support 
document and help-desk for ICT; and ICT providing emergency and relay services. 


Indian language users of computers, internet and mobiles have dramatically grown in the recent years and one 
study report has indicated that they have already exceeded English language users in India. The Government of 
India supports the delivery of e-Governance services in Indian languages as well. Hence, this standard has catered 
to the accessibility requirements of Indian language users of ICT products and services in all categories. 


This standard captures functional performance requirements from the set of functional disability categories 
and covers the technical requirements for each category of use situations in detail. These have been stated in a 
verifiable way to ensure testing and compliance of ICT products and services to requirements for the benefit of 
developers and users. 


Indian Standard 


ACCESSIBILITY FOR THE ICT PRODUCTS 
AND SERVICES 


PART 1 REQUIREMENTS 


1 SCOPE 


This standard (Part 1) specifies the needs of people 
with visual, auditory, speech, physical and neurological 
disabilities and those with limited cognition, language, 
and learning applicable to ICT products and services 
in terms of functional performance statements. It 
then covers the generic technical requirements for 
various kinds of ICT to meet functional performance 
statements. 


In line with the RPwD Act 2016, this standard covers 
a wide range of ICT products and services relating to 
information and communication, including telecom 
services, web-based services, electronic and print 
services, digital and virtual services. 


This standard (Part 1) is intended to be used in the context 
of web based technologies, non-web technologies and 
those that use both. It covers software, hardware and 
content as well as services. The conformance criteria 
on test descriptions and evaluation methodology are 
covered in Part 2 of this standard. 


2 REFERENCES 


The standards or other publications given below 
contain provisions which, through reference in this 
text, constitute provisions of this standard. At the time 
of publication, the editions indicated were valid. All 
standards or other publications are subject to revision, 
and parties to agreements based on this standard are 
encouraged to investigate the possibility of applying 
the most recent editions of the standards or other 
publications. 


ANSI/IEEE C63.19 
(2011) 


American National Standard 
Method of Measurement 
of Compatibility between 
Wireless Communication 
Devices and Hearing Aids 


ANSI/TIA-4965 Receive volume o control 
reguirements for digital and 


analogue wireline terminals 


Character Encoding: 
01: 2009 


ETSI ETS 300 
381 (Edition 1) 
(December 1994) 


ETSI ES 200 381-1 
(V1.2.1) 
(October 2012) 


ETSI ES 200 381-2 
(V1.1.1) 
(October 2012) 


ETSI EG 201 013 


ETSI ES 202 975 


ETSI ETS 300 767 


ETSITS 126 114 
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Character encoding standard 
for Indian languages, 
Document No: — Character 
Encoding: 01, Version: 1.0, 
November, 2009, Government 
of India, Department of 
Information Technology, 
Ministry of Communications 
and Information Technology 


Telephony for hearing 
impaired people; Inductive 
coupling of telephone 


earphones to hearing aids 


Telephony for hearing 
impaired people; Inductive 
coupling of telephone 


earphones to hearing aids; 


Part 1: Fixed-line speech 
terminals 

Telephony for hearing 
impaired people 

Human Factors (HF); 


Definitions, abbreviations and 
symbols 


Human Factors (HF); 
Requirements for relay 
services 

Human Factors (HF); 


Telephone Prepayment Cards; 
Tactile Identifier 


Universal Mobile 
Telecommunications System 
(UMTS); LTE; IP Multimedia 
Subsystem (IMS); Multimedia 
telephony; Media handling 
and interaction (3GPP TS 
26.114) 
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ETSI TS 122 173 


ETSI TS 134 229 


ETSI/CEN/ 
CENELEC EN 
301 549 (V2.1.2) 
(August 2018) 


GIGW v2.0 


Digital cellular 
telecommunications system 
(Phase 2+) (GSM); Universal 
Mobile Telecommunications 
System (UMTS); LTE; IP 
Multimedia Core Network 
Subsystem (IMS) Multimedia 
Telephony Service and 
supplementary services; 
Stage 1 (3GPP TS 22.173) 


Universal Mobile 
Telecommunications System 
(UMTS); LTE; Internet 
Protocol (IP) multimedia call 
control protocol based on 
Session Initiation Protocol 
(SIP) and Session Description 
Protocol (SDP); User 
Equipment (UE) conformance 


specification (3GPP TS 
34.229) 
Accessibility requirements 


for ICT products and services 


Guidelines for Indian 
Government Apps and 
Websites, v2.0, Feb, 2019, 
NIC, MeitY, GOT; 


Harmonized Guidelines and Space Standards for 
Barrier-Free Built Environment for persons with 
Disability and Elderly Persons, Feb-2016, 


IETF RFC 4103 
(2005): 


ISO/IEC 40500 : 
2012 


ISO/IEC 10646 : 
2012 


ISO 9241-11 : 2018 


ISO 9241-110: 
2006 


ISO 9241-171: 
2008 


“RTP Payload for Text 
Conversation 
Information technology 
— W3C Web Content 
Accessibility Guidelines 
(WCAG) 2.0 


Information technology — 
Universal Coded Character 
Set (UCS) 


Ergonomics of human- 
system interaction — Part 
11: Usability: Definitions and 
concepts 


Ergonomics of human-system 


interaction — Part 110: 
Dialogue principles 
Ergonomics of human- 
system interaction — Part 
171: Guidance on software 
accessibility 


ISO/IEC 13066-1 : 
2011 


ISO/IEC TS 20071- 
25:2017 


ISO 21542 : 2011 


ISO/IEC Guide 71 
: 2014 


IS 16333 (Part 3) : 
2017 


IS 16350: 2016 


IS/ISO/IEC 14496- 
22:2019 


Mol&B 
Accessibility 
Standard 


Recommendation 
ITU-TE.161 
(2001) 


Recommendation 
ITU-T G.722 
(1988) 


Recommendation 
ITU-T G.722.2 
(2003) 


Recommendation 
ITU-T V.18 (2000) 


Recommendation 
ITU-T T.140 
(1988): 


Information technology 
— Interoperability with 
assistive technology (AT) 
— Part 1: Requirements 
and recommendations for 
interoperability 


Information technology — 
User interface component 
accessibility — Part 25: 
Guidance on the audio 
presentation of text in videos, 
including captions, subtitles 
and other on-screen text 


Building construction — 
Accessibility and usability of 
the built environment 


Guide for addressing 
accessibility in standards 


Mobile phone handsets: Part 
3 Indian language support 
for mobile phone handsets — 
Specific requirements (first 
revision) 


Enhanced Inscript Keyboard 
Layouts 


Information technology 
— Coding of audio-visual 
objects: Part 22: Open font 
format 


Accessibility Standards for 
Persons with Disabilities in 
TV Programs, 11-Sep-19, 
Mol&B 


Arrangement of digits, letters 
and symbols on telephones 
and other devices that can be 
used for gaining access to a 
telephone network 


7 kHz audio-coding within 64 
kbit/s 


Wideband coding of speech 
at around 16 kbit/s using 
Adaptive Multi-Rate 
Wideband (AMR-WB) 


Operational and interworking 
requirements for DCEs 
operating in the text telephone 
mode 


Protocol for multimedia 
application text conversation 


Recommendation Multimedia conversational 
ITU-T F.703 services 
(2000) 


TIA-1083-A (2010) Telecommunications; 
Telephone Terminal 
eguipment; Handset magnetic 
measurement procedures and 


performance reguirements 


W3C Web Schemas/ NOTE: Available at 


Accessibility 2.0. o https://www.w3.org/wiki/ 
WebSchemas/Accessibility 
WCAG2ICT W3C Working Group Note 5 


September 2013, Guidance 
on Applying WCAG 2.0 


to Non-Web Information 
and Communications 
Technologies 


WCAG 2.1 : 2018 Web Content Accessibility 


Guidelines (WCAG) 2.1 
NOTE: Available at WCAG 2.1. 


3 TERMINOLOGY AND ABBREVIATIONS 


3.1 Terminology 


For the purposes of this standard, the terms given in 
ETSI EG 201 013 and the following shall apply: 


3.1.1 Accessibility — Extent to which products, 
systems, services, environments and facilities can 
be used by people from a population with the widest 
range of user needs, characteristics and capabilities, to 
achieve identified goals in identified contexts of use 
(source ISO 9241-11 : 2018). 


NOTES 
1 Context of use includes direct use or use supported by 
assistive technologies. 


2 The context in which the ICT is used may affect its overall 
accessibility. This context could include other products and 
services with which the ICT may interact. 


3.1.2 Access Space — Space intended to be occupied 
by the person, including their Assistive Technology, 
while they are using the product. 


3.1.3 Assistive Listening Devices (ALDs) — Devices 
that help separate the sounds, particularly speech, 
that a person wants to hear from background noise by 
bringing sound directly into the ear 
NOTE — These are often found in meetings and public venues 
such as plays, concerts and places of worship. They can also be 


used at home with televisions and other products with auditory 
output. 


3.1.4 Assistive Technology (AT) — Equipment, 
product system, hardware, software or service that is 
used to increase, maintain or improve capabilities of 
individuals (source ISO/IEC Guide 71 : 2014). 
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NOTES 
1 Assistive technology is an umbrella term that is broader than 
assistive products. 


2 Assistive technology can include assistive services, and 
professional services needed for assessment, recommendation 
and provision. 


3 Where ICT does not support directly connected assistive 
technology, but which can be operated by a system connected 
over a network or other remote connection, such a separate 
system (with any included assistive technology) can also be 
considered assistive technology. This is an additional note, not 
included in ISO/IEC Guide 71 : 2014. 


3.1.5 Audio Description — additional audible narrative, 
interleaved with the dialogue, which describes the 
significant aspects of the visual content of audio- 
visual media that cannot be understood from the main 
soundtrack alone. 


NOTE — This is also variously described using terms such as 
“video description” or variants, such as “descriptive narration”. 


3.1.6 Authoring Tool — software that can be used to 
create or modify content 


NOTES 

1 An authoring tool may be used by a single user or multiple 
users working collaboratively. 

2 An authoring tool may be a single stand-alone application or 
be comprised of collections of applications. 


3 An authoring tool may produce content that is intended for 
further modification or for use by end-users. 


3.1.7 Caption — Synchronized visual and/or text 
alternative for both speech and non-speech audio 
information needed to understand the media content 
(source : WCAG 2.1). 


NOTES 


1 This is also variously described using terms, such as 
“subtitles” or variants, such as “subtitles for the deaf and 
hard-of-hearing”. 

2 Open Captioning : The captioning whereby the user does 
not have to do anything in order to see captions for the hearing 
impaired’ as these are an integral part of the picture and cannot 
be turned off [source: Mol&B Accessibility Standard] 

3 Closed Captioning : The means by which both the audio 
dialogue and sound representations of audio-video content 
are made visible via onscreen text that is synchronized with 
the audio content on demand by the user [source : Mol&B 
Accessibility Standard]. 

4 Sub-titling : The captioning of dialogues whereby the user 
does not have to do anything in order to see such sub-titles 
for the hearing impaired, as these are an integral part of the 
picture and cannot be turned off [source: MoI&B Accessibility 
Standard]. 


3.1.8 Closed Functionality — Functionality that is 
limited by characteristics that prevent a user from 
attaching, installing or using assistive technology. 


3.1.9 Content — Information and sensory experience 
to be communicated to the user by means of 
software, including code or mark-up that defines the 
content’s structure, presentation, and interactions 
(source: WCAG2ICT). 
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NOTE — Content occurs in three places: web pages, 
documents and software. When content occurs in a web page 
or a document, a user agent is needed in order to communicate 
the content’s information and sensory experience to the user. 
When content occurs in software, a separate user agent is not 
needed in order to communicate the content’s information and 
sensory experience to the user - the software itself performs 
that function. 


3.1.10 Context of Use — Combination of users, 
goals and tasks, resources, and environment (source: 
ISO 9241-11 : 2018). 


NOTE — The “environment” in a context of use includes 
the technical, physical, social, cultural and organizational 
environments. 


3.1.11 Document — Logically distinct assembly of 
content (such as a file, set of files, or streamed media) 
that functions as a single entity rather than a collection, 
that is not part of software and that does not include its 
own user-agent (source: WCAG2ICT). 


NOTES 


1 A document always requires a user agent to present its 
content to the user. 

2 Letters, e-mail messages, spreadsheets, books, pictures, 
presentations, and movies are examples of documents. 

3 Software configuration and storage files, such as databases 
and virus definitions, as well as computer instruction files, such 
as source code, batch/script files, and firmware, are examples 
of files that function as part of the software and thus are not 
examples of documents. If and where software retrieves 
“information and sensory experience to be communicated to 
the user” from such files, it is just another part of the content 
that occurs in software and is covered by WCAG2ICT like any 
other parts of the software. Where such files contain one or 
more embedded documents, the embedded documents remain 
documents under this definition. 


4 A collection of files zipped together into an archive, stored 
within a single virtual hard drive file, or stored in a single 
encrypted file system file, do not constitute a single document 
when so collected together. The software that archives/encrypts 
those files or manages the contents of the virtual hard drive 
does not function as a user agent for the individually collected 
files in that collection because that software is not providing a 
fully functioning presentation of that content. 


5 Anything that can present its own content without involving 
a user agent, such as a self-playing book, is not a document but 
is software. 

6 A single document may be composed of multiple files, such 
as the video content and closed caption text. This fact is not 
usually apparent to the end-user consuming the document/ 
content. 


7 An assembly of files that represented the video, audio, 
captions and timing files for a movie is an example of a 
document. 

8 A binder file used to bind together the various exhibits for a 
legal case would not be a document. 


9 Documents may contain sub-documents. 


3.1.12 Embedded — Directly included in the content 

that is downloaded to the user agent and its extension, 

and is intended to be used in rendering the web page. 
NOTE — Something that is downloaded using a mechanism 


on the web page but is not used in rendering the page is not 
“embedded” in the page. 


3.1.13 ICT Network — Technology and resources 
supporting the connection and operation of 
interconnected ICT. 


3.1.14 Information and Communication Technology 
(ICT) — Technology, equipment, or interconnected 
system or subsystem of equipment for which the 
principal function is the creation, conversion, 
duplication, automatic acquisition, storage, analysis, 
evaluation, manipulation, management, movement, 
control, display, switching, interchange, transmission, 
reception, or broadcast of data or information. 


NOTES 


1 Examples of ICT are web pages, electronic content, 
telecommunications products, computers and ancillary 
equipment, software including mobile applications, 
information kiosks and transaction machines, videos, IT 
services, and multifunction office machines that copy, scan, 
and fax documents. 


2 RPwD Act, 2016 defines, “ICT includes all services and 
innovations relating to information and communication, 
including telecom services, web-based services, electronic and 
print services, digital and virtual services.” 


3.1.15 Mechanically Operable Part — Operable part 
that has a mechanical interface to activate, deactivate, 
or adjust the ICT 


NOTE — Examples of mechanically operable parts include 
scanner covers, notebook docking stations and lids as well as 
physical switches and latches. 


3.1.16 Mechanism for Private Listening — Auditory 
output designed so that only the current user can 
receive the sound. 


NOTE — Personal headsets, directional speakers and audio 
hoods are examples of mechanisms for private listening. 


3.1.17 Non-text Content — Content that is not a 
sequence of characters that can be programmatically 
determined or where the sequence is not expressing 
something in human language (see WCAG 2.1). 


3.1.18 Non-web Document — Document that is not a 
web page, not embedded in web pages nor used in the 
rendering or functioning of the page. 


3.1.19 Non-web Software — Software that is not a 
web page, not embedded in web pages nor used in the 
rendering or functioning of the page. 


3.1.20 Open Functionality — Functionality that 
supports access by assistive technology. 


NOTE — This is the opposite of closed functionality. 


3.1.21 Operable Part — Component of ICT used to 
activate, deactivate, or adjust the ICT. 


NOTES 


1 Operable parts can be provided in either hardware 
(see mechanically operable parts, above) or software. An 
on-screen button is an example of an operable part provided 
by software. 


2 Operable parts do not include parts involved only in 
maintenance or repair or other actions that are not expected ofa 
typical user if the product is not malfunctioning. These actions 
include: clearing paper jams internal to the machine, replacing 
items or parts internal to the machine that may expose the 
end user to sharp or hot surfaces, replacing or repairing items 
designated by manufacturers as service or maintenance items 
in user documentation. 


3.1.22 Person with Disability (PwD) — A person with 
long term physical, mental, intellectual or sensory 
impairment which, in interaction with barriers, hinders 
his full and effective participation in society equally 
with others [source: RPwD Act, 2016]. 


3.1.23 Platform Software (Platform) — Collection 
of software components that runs on an underlying 
software or hardware layer, and that provides a set 
of software services to other software components 
that allows those applications to be isolated from 


the underlying software or hardware layer (source: 
ISO/IEC 13066-1). 


NOTE — A particular software component might play the role 
of a platform in some situations and a client in others. 


3.1.24 Programmatically Determinable — Able to be 
read by software from developer-supplied data in a way 
that other software, including assistive technologies, 
can extract and present this information to users in 
different modalities. 

NOTE — WCAG 2.1 uses “determined” where this definition 


uses “able to be read” (to avoid ambiguity with the word 
“determined”). 


3.1.25 Real-Time Text (RTT) — Form of a text 
conversation in point-to-point situations or in 
multipoint conferencing where the text being entered is 
sent in such a way that the communication is perceived 
by the user as being continuous. 


NOTES 


1 Users will perceive communication as continuous if the delay 
between text being created by the sender and received by the 
recipient is less than 500ms. However, the actual delay will be 
dependent on the communication network. 

2 The creation of text will differ between systems where text is 
entered on a word-by-word basis ( for example, speech-to-text 
and predictive-text based systems) and systems where each 
character is separately generated (for example, typing on a 
physical keyboard). 


3.1.26 Reasonable Accommodation — Necessary and 
appropriate modification and adjustments, without 
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imposing a disproportionate or undue burden in a 
particular case, to ensure to persons with disabilities 
the enjoyment or exercise of rights equally with others 
[source: RPwD Act, 2016]. 


3.1.27 Satisfies a Success Criterion — Success criterion 
does not evaluate to “false” when applied to the ICT 
(source: WCAG 2.1 : 2018). 


3.1.28 Single User Connection — Connection that 
consists of sound, RTT or video (or a combination of 
two or three of those media) that is established by a 
single user action. 
NOTE — Even though the different media may travel over 
different channels, and more than one piece of hardware may 
be involved, it appears to the user like a single connection, 
and is treated by any intermediate technologies (for example, 
network, auto-reception) as a single connection for purposes 
such as transfer. 


3.1.29 Sign Language (or Signing Language) — A 
language, instead of acoustically conveyed sound 
patterns, uses visually transmitted sign patterns (manual 
communication, body language) to convey meaning 
simultaneously combining hand shapes, orientation 
and movement of the hands, arms or body, and facial 
expressions to fluidly express a speaker’s thoughts 
(source: MoI&B accessibility standard). 


3.1.30 Sign Language Interpretation — Sign language 
of the programme audio (speech and other sounds) 
for viewers who are hearing impaired and use sign 
language. Whenever reference is made to ‘sign 
language’ in the Indian context’ it will refer to a variant 
of it called ‘Indian Sign Language’ (ISL) (source 
Mol&B accessibility standard). 


3.1.31 Spoken Captions/Subtitles Audio Captions/ 
Subtitles — Captions/subtitles that are voiced over the 
audio-visual content (source ISO/IEC TS 20071-25). 


3.1.32 Stationary ICT — ICT that stands on the floor, or 
is mounted on a wall or other immovable structure, and 
is not intended to be moved by its user. 


NOTES 


1 Typically, stationary ICT rests on the ground (such as an 
information kiosk) or is installed in a wall (such as a machine 
that dispenses cash or performs other banking services). 

2 A manufacturer cannot control the height of ICT that is put on 
a table by someone else, but they are able to control the reach 
dimensions of self-contained ICT that rests on the ground and 
can specify the heights for installation in walls. 


3.1.33 Terminal — Combination of hardware and/or 
software with which the end user directly interacts and 
that provides the user interface. 


NOTES 

1 The hardware may consist of more than one device working 
together for example, a mobile device and a computer. 

2 For some systems, the software that provides the user 
interface may reside on more than one device such as a 
telephone and a server. 
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3.1.35 Turn-taking — Ttype of organization in 


ti d di h Mn k ATAG Authoring Tool Accessibility 
conversation and discourse where participants spea Guidelines (of W3C) 
one at a time in alternating turns. - 
CPWD Central Public Works Department 
3.1.36 User Agent — software that retrieves and p 
CSS Cascading Style Sheets 
presents content for users (source WCAG 2.1: 2018). Bay — - 
NOTES DARPG Department of Administrative 
, f Ke Reforms and Public Grievances 
1 Software that only displays the content contained within it is 
treated as software and not considered to be a user agent. DOM Document Object Model 
2 An example of software that is not a user agent is a calculator EU European Union 
application that does not retrieve the calculations from outside 
the software to present it to a user. In this case, the calculator FPS Frames Per Second 
iie is not a user agent, it is simply software with a user FXML XML-based user interface markup 
i , language 
3 Software that only shows a preview of content such as a SER F 
thumbnail or other non-fully functioning presentation is not GIGW Guidelines for Indian Government 
providing user agent functionality. Apps and Websites 
3.1.37 Universal Design — The design of products, | HTML Hyper Text Markup Language 
environments, programmes and services to be usable | HTTP Hyper Text Transfer Protocol 
by all people to the greatest extent possible, without the ICT m and nm 
need for adaptation or specialised design and shall apply Technol 
to assistive devices including advanced technologies eee 
for particular group of persons with disabilities. IETF Internet Engineering Task Force 
3.1.38 User Interface — All components of an Me A ee en 
interactive system (software or hardware) that provide | INSCRIPT Indian Script 
information and/or controls for the user to accomplish | Jp Internet Protocol 
specific tasks with the interactive system (source ISCH Tadian Sernt Code fur Information 
ISO 9241-110). 
Interchange 
3.1.39 User Interface Element — Entity of the user | [SL Indian Sign Language 
çi e that is presented to the user by the software ITU-T emini tea ini ali 
(Source: ISO 9241-171). f NE 
Union - Telecommunication 
NOTES standardization sector 
1 This term is also known as “user interface component”. LED Lig ht Emitting Device 
2 User-interface elements can be interactive or not. 
MeitY Ministry of Electronics and 
3.1.40 Web Content = Content that belongs to a web Information Technology, Gol 
page, and that is used in the rendering or that is intended — 
to be used in the rendering of the web page. Mol&B Ministry _ of Information and 
Broadcasting, Gol 
3.1.41 Web Page — Non-embedded resource obtained MoUD Ministry of Housing and Urban 
from a single URI using HTTP plus any other resources Affáirs: Gol 
that are used in the rendering or intended to be rendered — - 
together with it by a user agent (source: WCAG 2.1: | NC National Informatics Centre 
2018). ODF Open Document Format 
3.2 Symbols OOXML Office Open eXtensible Markup 
> Language 
Void : : 
PSTN Public Switched Telephone 
3.3 Abbreviations Network 
For the purposes of this standard, the following | PwD Person with Disabilities 
abbreviations apply: QVGA Quarter Video Graphics Array 
Abbreviation Description RBI Reserve Bank of India 
ANSI American National Standards RFC Request For Comment 
Institute RPwD Rights of Persons with Disabilities 
AT Assistive Technology Act, 2016 
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RTT Real-Time Text 

SIP Session Initiation Protocol 

STQC Standardization Testing and Quality 
Certification directorate, Gol 

TRAI Telecom Regulatory Authority of 
India, Gol 

UAAG User Agent Accessibility 
Guidelines (of W3C) 

URI Uniform Resource Identifier 

USB Universal Serial Bus 

VGA Video Graphics Array 

VOIP Voice Over IP 

W3C World Wide Web Consortium 

WAI Web Accessibility Initiative 

WCAG Web Content Accessibility 
Guidelines (of W3C/WAT) 

WLAN Wireless Local Access Network 

XML eXtensible Markup Language 

XUL XML User interface Language 


4 FUNCTIONAL PERFORMANCE 


4.1 Meeting Functional Performance Statements 


The statements set out in 4.2 are intended to describe 
the functional performance of ICT enabling people 
to locate, identify, and operate ICT functions, and to 
access the information provided, regardless of physical, 
cognitive or sensory abilities. Any differences in ability 
may be permanent, temporary or situational. The 
requirements in 5 to 13 provide specific testable criteria 
for accessible ICT, corresponding to the user needs 
reflected in 4.2. 


NOTES 


1 The relationship between the requirements from 5 to 13 and 
the functional performance statements is set out in Annex B. 


2 The intent of 4.2 is to describe the ICT performance in enabling 
users to access the full functionality and documentation of 
the product or the service with or without the use of assistive 
technologies. 


3 The methods of meeting the accessibility needs of users with 
multiple access needs will depend on the specific combination 
of needs. Meeting these user accessibility needs may be 
addressed by considering multiple clauses in 4.2. 


4 Several users’ accessibility needs rely on ICT providing 
specific modes of operation. If a user is to activate, engage 
or switch to the mode that complies with his or her user 
accessibility needs, the method for activating, engaging or 
switching to that mode would need to comply with the same 
user accessibility needs. 


4.2 Functional Performance Statements 


4.2.1 Usage Without Vision 


Where ICT provides visual modes of operation, the ICT 
provides at least one mode of operation that does not 
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require vision. This is essential for users without vision 
and benefits many more users in different situations. 


NOTES 


1 A web page or application with a well-formed semantic 
structure can allow users without vision to identify, navigate 
and interact with a visual user interface. 


2 Audio, tactile and haptic user interfaces may contribute 
towards meeting this clause. 


4.2.2 Usage with Limited Vision 


Where ICT provides visual modes of operation, the 
ICT provides features that enable users to make better 
use of their limited vision. This is essential for users 
with limited vision and benefits many more users in 
different situations. 


NOTES 


1 Magnification, reduction of required field of vision and 
control of contrast, brightness and intensity can contribute 
towards meeting this clause. 


2 Where significant features of the user interface are dependent 
on depth perception, the provision of additional methods of 
distinguishing between the features may contribute towards 
meeting this clause. 


3 Users with limited vision may also benefit from non-visual 
access (see 4.2.1). 


4.2.3 Usage without Perception of Colour 


Where ICT provides visual modes of operation, the 
ICT provides a visual mode of operation that does not 
require user perception of colour. This is essential for 
users with limited colour perception and benefits many 
more users in different situations. 
NOTE — Where significant features of the user interface 
are colour-coded, the provision of additional methods of 


distinguishing between the features may contribute towards 
meeting this clause. 


4.2.4 Usage without Hearing 


Where ICT provides auditory modes of operation, the 
ICT provides at least one mode of operation that does 
not require hearing. This is essential for users without 
hearing and benefits many more users in different 
situations. 


NOTES 


1 Visual and tactile user interfaces, including those based on 
sign language, may contribute towards meeting this clause. 

2 In respective of sign language, Indian Sign Language (ISL) 
may be supported. 


3 Captioning and Sub-titling will also contribute to meeting 
this clause, especially in respect of broadcast TV programs or 
streamed video or audio or in video conferencing meetings. 


4.2.5 Usage with Limited Hearing 


Where ICT provides auditory modes of operation, the 
ICT provides enhanced audio features. This is essential 
for users with limited hearing and benefits many more 
users in different situations. 


NOTES 


1 Enhancement of the audio clarity, reduction of background 
noise, providing a joint monaural option, adjustment of balance 
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of both audio channels, increased range of volume and greater 
volume in the higher frequency range can contribute towards 
meeting this clause. 


2 Allowing the use of Assistive Listening Devices, such 
as headsets with noise cancellation (connected by cable, 
Bluetooth or WLAN) can contribute towards meeting this 
clause. 


3 Users with limited hearing may also benefit from non-hearing 
access (see 4.2.4). 


4.2.6 Usage with no or Limited Vocal Capability 


Where ICT requires vocal input from users, the ICT 
provides at least one mode of operation that does not 
require them to generate vocal output. This is essential 
users with no or limited vocal capability and benefits 
many more users in different situations. 


NOTES 


1 Vocal output includes speech and other orally generated 
sounds, such as whistles and clicks. 


2 Keyboard, pen or touch user interfaces may contribute 
towards meeting this clause. 


4.2.7 Usage with Limited Manipulation or Strength 


Where ICT requires manual actions, the ICT provides 
features that enable users to make use of the ICT 
through alternative actions not requiring manipulation, 
simultaneous action or hand strength. This is essential 
for users with limited manipulation or strength and 
benefits many more users in different situations. 


NOTES 


1 Examples of operations that users may not be able to perform 
include those that require fine motor control, path dependant 
gestures, pinching, twisting of the wrist, tight grasping, or 
simultaneous manual actions. 

2 One-handed operation, sequential key entry and speech user 
interfaces may contribute towards meeting this clause. 


3 Some users have limited hand strength and may not be 
able to achieve the level of strength to perform an operation. 
Alternative user interface solutions that do not require hand 
strength may contribute towards meeting this clause. 


4.2.8 Usage with Limited Reach 


Where ICT products are free-standing or installed, all 
the elements required for operation will need to be 
within reach of all users. This is essential for users with 
limited reach and benefits many more users in different 
situations. 


NOTES 


1 Considering the needs of wheelchair users and the range of 
user statures in the placing of operational elements of the user 
interface may contribute towards meeting this clause. 


2 Considering the differences in reach-range of ICT of Indian 
users, including those with disabilities, the design of public 
places and installation of information kiosks, ATMs, Ticketing 
machines and the like, needs to meet Indian user needs. 


4.2.9 Minimize Photosensitive Seizure Triggers 


Where ICT provides visual modes of operation, the ICT 
provides at least one mode of operation that minimizes 
the potential for triggering photosensitive seizures. 
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This is essential for users with photosensitive seizure 
triggers. 


NOTE — Limiting the area and number of flashes per second 
may contribute towards meeting this clause. 


4.2.10 Usage with Limited Cognition, Language or 
Learning 


The ICT provides features and/or presentation that 
makes it simpler and easier to understand, operate and 
use. This is essential for users with limited cognition, 
language or learning, and benefits many more users in 
different situations. 


NOTES 


1 Adjustable timings, error indication and suggestion, and a 
logical focus order are examples of design features that may 
contribute towards meeting this clause. 

2 Providing an audio output of the text is an example of 
providing support for people with limited reading abilities. 

3 Providing spelling aid and word prediction of the text is an 
example of providing support for people with limited writing 
abilities. 

4 Interaction with content can be made easier, and less prone to 
errors, by presenting tasks in steps that are easy to follow. 


4.2.11 Privacy 


Where ICT provides features for accessibility, the ICT 
maintains the privacy of users of these features at the 
same level as other users. 
NOTE — Enabling the connection of personal headsets for 
private listening, not providing a spoken version of characters 
being masked and enabling user control of legal, financial 
and personal data are examples of design features that may 
contribute towards meeting this clause. 


4.2.12 Support to Indian Languages 


Accessibility support shall be provided in respect of 
all the features, functions or contents provided by the 
ICT, in respect of all the Indian languages figuring in 
the eighth schedule of the Indian constitution. This is 
essential to support users with disabilities to understand, 
comprehend, use and operate the functions of the ICT 
at the same level or better in these languages. 


5 GENERIC REQUIREMENTS 


5.1 Closed Functionality 


5.1.1 Introduction (Informative) 


ICT has closed functionality for many reasons, including 
design or policy. Some of the functionality of products 
can be closed because the product is self-contained and 
users are precluded from adding peripherals or software 
in order to access that functionality. 


ICT may have closed functionality in practice even 
though the ICT was not designed, developed or supplied 
to be closed. 


Computers that do not allow end-users to adjust settings 
or install software are functionally closed. 


5.1.2 General 


5.1.2.1 Closed functionality 


Where ICT has closed functionality, it shall meet the 
requirements set out in clauses 5.2 to 13, as applicable. 
Indian language requirements shall be met through 
support to UNICODE (source ISO/IEC 10646), display 
(source IS/ISO/IEC 14496-22 : 2009), inputting of 
text in mobile phones (source IS 16333-3), encoding 
and Enhanced INSCRIPT keyboard layouts (source 
IS 16350 : 2016) and encoding standards (source 
Character Encoding: 01: 2009) 


NOTES 


1 ICT may close some, but not all, of its functionalities. Only 
the closed functionalities have to conform to the requirements 
of 5.1. 


2 The requirements within this clause replace those in 5.2 
to 13 that specifically state that they do not apply to closed 
functionality. This may be because they relate to compatibility 
with assistive technology or to the ability for the user to 
adjust system accessibility settings in products with closed 
functionality (for example, products that prevent access to the 
system settings control panel). 


3 Whenever an Indian language is chosen by the user, the 
device or the closed function shall support the same. 


5.1.2.2 Assistive technology 


Where ICT has closed functionality that closed 
functionality shall be operable without requiring the 
user to attach, connect or install assistive technology 
and shall conform to the generic requirements of 5.1.3 
to 5.1.6 as applicable. Personal headsets and personal 
induction loops shall not be classed as assistive 
technology for the purpose of this clause. 


5.1.3 Nonvisual Access 


5.1.3.1 Non-visual output of visual information 


Where visual information is needed to enable the use 
of those functions of ICT that are closed to assistive 
technologies for screen reading, ICT shall provide at 
least one mode of operation using non-visual access to 
enable the use of those functions. 


NOTES 


1 Non-visual access may be in an audio form, including 
speech, or in haptic form or in tactile form, such as braille for 
deaf- blind users. 


2 The visual information needed to enable use of some 
functions may include operating instructions and orientation, 
transaction prompts, user input verification, error messages 
and non-text content. 


3 Whenever an Indian language is chosen by the user, 
non-visual access shall also support the same Indian language. 


5.1.3.2 Auditory output delivery including speech 


Where auditory output is provided as non-visual access 
to closed functionality, the auditory output shall be 
delivered: 
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a) either directly by a mechanism included in or 
provided with the ICT; or 


by a personal headset that can be connected 
through a 3.5 mm audio jack, or an industry 
standard connection, without requiring the use of 
vision. 
NOTES 


1 Mechanisms included in or provided with ICT may be, but 
are not limited to, a loudspeaker, a built-in handset/headset, or 
other industry standard coupled peripheral. 


b) 


2 An industry standard connection could be a wireless 
connection. 

3 Some users may benefit from the provision of an inductive 
loop. 

4 ‘Where an Indian language .is chosen by the user, auditory 
output shall also be provided in the same language chosen by 
the user. 


5.1.3.3 Auditory output correlation 


Where auditory output is provided as non-visual 
access to closed functionality, and where information 
is displayed on the screen, the ICT should provide 
auditory information that allows the user to correlate 
the audio with the information displayed on the screen. 


NOTES 


1 Many people who are legally blind still have visual ability, 
and use aspects of the visual display even if it cannot be fully 
comprehended. An audio alternative that is both complete 
and complementary includes all visual information such as 
focus or highlighting, so that the audio can be correlated with 
information that is visible on the screen at any point in time. 


2 Examples of auditory information that allows the user to 
correlate the audio with the information displayed on the 
screen include structure and relationships conveyed through 
presentation. 


5.1.3.4 Speech output user control 


Where speech output is provided as non-visual access to 
closed functionality, the speech output shall be capable 
of being interrupted and repeated when requested by 
the user, where permitted by security requirements. 


NOTES 


1 It is best practice to allow the user to pause speech output 
rather than just allowing them to interrupt it. 


2 It is best practice to allow the user to repeat only the most 
recent portion rather than requiring play to start from the 
beginning. 


5.1.3.5 Speech output automatic interruption 


Where speech output is provided as non-visual access 
to closed functionality, the ICT shall interrupt current 
speech output when a user action occurs and when new 
speech output begins. 
NOTE — Where it is essential that the user hears the entire 
message, for example, a safety instruction or warning, the 


ICT may need to block all user action so that speech is not 
interrupted. 
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5.1.3.6 Speech output for non-text content 


Where ICT presents non-text content, the alternative for 
non-text content shall be presented to users via speech 
output unless the non-text content is pure decoration or 
is used only for visual formatting. The speech output 
for non-text content shall follow the guidance for “text 
alternative” described in WCAG 2.1 Success Criterion 
1.1.1. 


NOTE — Such non-text content shall be in the same Indian 
language chosen by the user. 


5.1.3.7 Speech output for video information 


Where pre-recorded video content is needed to enable 
the use of closed functions of ICT and where speech 
output is provided as non-visual access to closed 
functionality, the speech output shall present equivalent 
information for the pre-recorded video content. 


NOTES 


1 This speech output can take the form of an audio description 
or an auditory transcript of the video content. 


2 This speech output shall be in the same Indian language 
chosen by the user. 


5.1.3.8 Masked entry 


Where auditory output is provided as non-visual access 
to closed functionality, and the characters displayed 
are masking characters, the auditory output shall not 
be a spoken version of the characters entered unless 
the auditory output is known to be delivered only to a 
mechanism for private listening, or the user explicitly 
chooses to allow non-private auditory output. 


NOTES 


1 Masking characters are usually displayed for security 
purposes and include, but are not limited to asterisks 
representing personal identification numbers. 


2 Unmasked character output might be preferred when closed 
functionality is used, for example, in the privacy of the user’s 
home. A warning highlighting privacy concerns might be 
appropriate to ensure that the user has made an informed 
choice. 


3 The masked and unmasked character outputs shall be in the 
same Indian language chosen by the user. 


5.1.3.9 Private access to personal data 


Where auditory output is provided as non-visual access 
to closed functionality, and the output contains data that 
is considered to be private according to the applicable 
privacy policy, the corresponding auditory output shall 
only be delivered through a mechanism for private 
listening that can be connected without requiring 
the use of vision, or through any other mechanism 
explicitly chosen by the user. 


NOTES 


1 This requirement does not apply in cases where data is not 
defined as being private according to the applicable privacy 
policy or where there is no applicable privacy policy. 

2 Non-private output might be preferred when closed 
functionality is used, for example, in the privacy of the 
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user’s home. A warning highlighting privacy concerns might 
be appropriate to ensure that the user has made an informed 
choice. 


3 Privacy preserving output shall also be in the same language 
chosen by the user. The warning highlighting privacy shall also 
be in the same language. 


5.1.3.10 Non interfering audio output 


Where auditory output is provided as non-visual 
access to closed functionality, the ICT shall not 
automatically play, at the same time, any interfering 
audible output that lasts longer than three seconds. 


5.1.3.11 Private listening volume 


Where auditory output is provided as non-visual 
access to closed functionality and is delivered 
through a mechanism for private listening, ICT shall 
provide at least one non-visual mode of operation for 
controlling the volume. 


5.1.3.12 Speaker volume 


Where auditory output is provided as non-visual 
access to closed functionality and is delivered through 
speakers on ICT, a non-visual incremental volume 
control shall be provided with output amplification up 
to a level of at least 65 dBA (—29 dBPaA). 


NOTE — For noisy environments, 65 dBA may not be 
sufficient. 


5.1.3.13 Volume reset 


Where auditory output is provided as non-visual 
access to closed functionality, a function that resets 
the volume to be at a level of 65 dBA or less after 
every use, shall be provided, unless the ICT is 
dedicated to a single user. 

NOTE — A feature to disable the volume reset function may 


be provided in order to enable the single-user exception to be 
met. 


5.1.3.14 Spoken languages 


Where speech output is provided as non-visual access 
to closed functionality, speech output shall be in 
the same human language as the displayed content 
provided, except: 


a) for proper names, technical terms, words of 
indeterminate language, and words or phrases 
that have become part of the vernacular of the 
immediately surrounding text; 

b) where the content is generated externally and not 

under the control of the ICT vendor, the present 

clause shall not be required to apply for languages 
not supported by the ICT’s speech synthesizer; 

c) for displayed languages that cannot be selected 

using non-visual access; and 

d) where the user explicitly selects a speech 

language that is different from the language of 


the displayed content. 


5.1.3.15 Non-visual error identification 


Where speech output is provided as non-visual access to 
closed functionality and an input error is automatically 
detected, speech output shall identify and describe the 
item that is in error. 


NOTE — The speech output of the error message shall be in 
the same Indian language chosen by the user. 


5.1.3.16 Receipts, tickets, and transactional outputs 


Where ICT is closed to visual access and provides 
receipts, tickets or other outputs as a result of a 
self-service transaction, speech output shall be 
provided which shall include all information necessary 
to complete or verify the transaction. In the case of 
ticketing machines, printed copies of itineraries and 
maps shall not be required to be audible. 


NOTES 


1 The speech output may be provided by any element of the 
total ICT system. 


2 The speech output may be provided in the same language 
chosen by the user, immaterial of the language of the text 
contained in the receipt, ticket or other outputs. 


3 In respect of transactions involving payment gateways, the 
choice of Indian language by the user shall be respected during 
the entire course of the transaction. 


5.1.4 Functionality Closed to Text Enlargement 


Where any functionality of ICT is closed to the text 
enlargement features of platform or assistive technology, 
the ICT shall provide a mode of operation where the 
text and images of text necessary for all functionality is 
displayed in such a way that a non-accented capital “H” 
subtends an angle of at least 0.7 degrees at a viewing 
distance specified by the supplier. 


The subtended angle, in degrees, may be calculated 
from: 


Y = (180 x H)/(a x D) 
where 
w= the subtended angle in degrees; 
H= the height of the text; and 
D= the viewing distance. 
D and H are expressed in the same units. 
NOTES 


1 The intent is to provide a mode of operation where text is 
large enough to be used by most users with low vision. 

2 Table 1 and Fig. 1 illustrate the relationship between the 
maximum viewing distance and minimum character height at 
the specified minimum subtended angle. 

3 In respect of Indian language as a choice of display, chosen 
sentence spacing and fonts have to ensure that successive 
sentences and characters do not stick to each other, obstructing 


a clear reading of characters and words (source IS/ISO/IEC 
14496-22 : 2015). 
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Table 1 Relationship between Maximum Design 
Viewing Distance and Minimum Character Height 
at the Limit of Subtended Angle 


| Clause 5.1.4, Note 2 | 


Minimum Maximum Design Minimum 
Subtended Angle Viewing Distance Character Height 

100 mm 1.2mm 
200 mm 2.4mm 
250 mm 3.1 mm 
300 mm 3.7 mm 
350 mm 4.3 mm 

0.7 degrees 
400 mm 4.9 mm 
450 mm 5.5 mm 
500 mm 6.1 mm 
550 mm 6.7 mm 
600 mm 7.3 mm 


5.1.5 Visual Output for Auditory Information 


Where auditory information is needed to enable the use 
of closed functions of ICT, the ICT shall provide visual 
information that is equivalent to the auditory output. 


NOTES 


1 This visual information can take the form of captions or text 
transcripts. 


2 Whenever an Indian language is supported, the visual output 
and auditory information shall be in the same language as the 
one chosen by the user. 


5.1.6 Operation without Keyboard Interface 


5.1.6.1 Closed functionality 


Where ICT functionality is closed to keyboards or 
keyboard interfaces, all functionality shall be operable 
without vision as required by 5.1.3. 


5.1.6.2 Input focus 


Where ICT functionality is closed to keyboards or 
keyboard interfaces and where input focus can be 
moved to a user interface element, it shall be possible to 
move the input focus away from that element using the 
same mechanism, in order to avoid trapping the input 
focus. 


5.1.7 Access without Speech 


Where speech is needed to operate closed functions 
of ICT, the ICT shall provide at least one mode of 
operation using an alternative input mechanism that 
does not require speech. 


NOTE — The alternative input shall be in the same Indian 
language chosen by the user. 
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Character height vs Viewing Distance 
for 0.7 degrees subtended angle 


100 200 


Minimum character height {mm} 


400 500 600 700 


Maximum design viewing distance (mm) 


Fic. 1 RELATIONSHIP BETWEEN MINIMUM CHARACTER HEIGHT 
AND MAXIMUM DESIGN VIEWING DISTANCE 


5.2 Activation of Accessibility Features 


Where ICT has documented accessibility features, 
it shall be possible to activate those documented 
accessibility features that are required to meet a specific 
need without relying on a method that does not support 
that need. 


5.3 Biometrics 


Where ICT uses biological characteristics, it shall not 
rely on the use of a particular biological characteristic 
as the only means of user identification or for control 
of ICT. 


NOTES 


1 Alternative means of user identification or for control of ICT 
could be non-biometric or biometric. 

2 Biometric methods based on dissimilar biological 
increase the likelihood that individuals 
with disabilities possess at least one of the specified 
biological characteristics. Examples of dissimilar biological 
characteristics are fingerprints, eye retinal patterns, voice, and 
face. 


characteristics 


5.4 Preservation of Accessibility Information during 
Conversion 


Where ICT converts information or communication 
it shall preserve all documented non-proprietary 
information that is provided for accessibility, to the 
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extent that such information can be contained in or 
supported by the destination format. 


5.5 Operable Parts 


5.5.1 Means of Operation 


Where ICT has operable parts that require grasping, 
pinching, or twisting of the wrist to operate, an 
accessible alternative means of operation that does not 
require these actions shall be provided. 


5.5.2 Operable Parts Discernibility 


Where ICT has operable parts, it shall provide a means 
to discern each operable part, without requiring vision 
and without performing the action associated with the 
operable part. 


NOTE — One way of meeting this requirement is by making 
the operable parts tactilely discernible. 


5.6 Locking or Toggle Controls 


5.6.1 Tactile or Auditory Status 


Where ICT has a locking or toggle control and the 
status of that control is visually presented to the user, 
the ICT shall provide at least one mode of operation 
where the status of the control can be determined either 
through touch or sound without operating the control. 


NOTES 


1 Locking or toggle controls are those controls that can only 
have two or three states and that keep their state while being 
used. 


2 An example of a locking or toggle control is the “Caps Lock” 
key found on most keyboards. Another example is the volume 
button on a pay telephone, which can be set at normal, loud, or 
extra loud volume. 


5.6.2 Visual Status 


Where ICT has a locking or toggle control and the status 
of the control is non-visually presented to the user, the 
ICT shall provide at least one mode of operation where 
the status of the control can be visually determined 
when the control is presented. The state before and 
after the toggle action should be presented in accessible 
form. 


NOTES 


1 Locking or toggle controls are those controls that can only 
have two or three states and that keep their state while being 
used. 


2 An example of a locking or toggle control is the “Caps Lock” 
key found on most keyboards. An example of making the 
status of a control determinable is a visual status indicator on a 
keyboard. 


5.7 Key Repeat 


Where ICT has a key repeat function that cannot be 
turned off: 


a) the delay before the key repeat shall be adjustable 
to at least 2 s; and 


b) the key repeat rate shall be adjustable down to one 
character per 2 s. 


5.8 Double-strike Key Acceptance 


Where ICT has a keyboard or keypad, the delay after 
any keystroke, during which an additional key-press 
will not be accepted if it is identical to the previous 
keystroke, shall be adjustable up to at least 0,5 s. 


5.9 Simultaneous User Actions 


Where ICT has a mode of operation requiring 
simultaneous user actions for its operation, such ICT 
shall provide at least one mode of operation that does 
not require simultaneous user actions to operate the 
ICT. 


NOTE — Having to use both hands to open the lid of a laptop, 
having to press two or more keys at the same time or having 
to touch a surface with more than one finger are examples of 
simultaneous user actions. 


5.10 Support to Indian Languages 


Where ICT offers a feature, functionality or content in 
any one or more of the twenty-two Indian languages 
mentioned in Schedule 8 of the Indian constitution, 
accessibility support shall be provided to the users who 
opt to use the ICT in any one or more of the Indian 
languages chosen by the user. These shall cover all 
aspects of perceivability, operability, understandability 
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and robustness as covered in 5.1 to 5.9 above and 
elsewhere in this standard in 6 to 13, wherever 
applicable, and in closed systems and open systems. 


5.10.1 Indian Language Requirements 


The Indian Language Requirements shall be met 
through support to UNICODE (source ISO/IEC 
10646), display (source IS/ISO/TEC 14496-22 : 2015), 
inputting of text in mobile phones ( source IS 16333-3), 
encoding and Enhanced INSCRIPT keyboard layouts 
(source IS 16350 : 2016) and encoding standards 
(Source: Character Encoding: 01: 2009) 


NOTES 

1 In respect of desktop/laptop, enhanced INSCRIPT keyboard 
layouts covered in IS 16350 : 2016 is the preferred standard. 

2 As regards the system input, output, storage and 
display, the ICT product/system/service shall follow the 
internationalization (i18n), localization (110n), globalization 
(glin), localizability (112y) standards/guidelines; they shall 
support internationalization in domain names and mail 
servers; they shall follow Indian language standards. It is 
desirable to provide inputting and display of text in the same 
Indian language of choice of the user for speech. For Indian 
languages, Indian standards related to keyboard and fonts shall 
be provided and made use of. There are many file formats, 
storage standards etc. Herein, it is expected that for Indian 
languages text storage unicode encoding to be used in 5.11 
support to Indian Sign Language (ISL) 


5.11 Indian Sign Language 


In respect of use of sign language to address the needs 
of hearing impaired, Indian Sign Language (ISL) shall 
be used. 


5.12 Captioning and Sub-titling 


In respect of use of captioning and sub-titling to address 
the needs of hearing impaired, especially in support 
of broadcast video or streaming video content or in 
support of video conferencing platforms, the standard 
issued by Ministry of Information and Broadcasting 
may be followed. 


6 ICT WITH 
COMMUNICATION 


TWO-WAY VOICE 


6.1 Audio Bandwidth for Speech 


Where ICT provides two-way voice communication, 
in order to provide good audio quality, that ICT 
shall be able to encode and decode two-way voice 
communication with a frequency range with an upper 
limit of at least 7000 Hz. 


NOTES 


1 For the purposes of interoperability, 
Recommendation ITU-T G.722 is widely used. 


2 Where codec negotiation is implemented, other standardized 
codecs, such as Recommendation ITU-T G.722.2 are 
sometimes used so as to avoid transcoding. 


6.2 Real-Time Text (RTT) Functionality 


support of 
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6.2.1 RTT Provision 


6.2.1.1 RTT communication 


Where ICT is in a mode, that provides a means for 
two-way voice communication, the ICT shall provide 
a means for two-way RTT communication, except 
where this would require design changes to add input 
or output hardware to the ICT. 


NOTES 


1 This requirement includes those products which do not 
have physical display or text entry capabilities but have the 
capability to connect to devices that do have such capabilities. 
It also includes intermediate ICT between the endpoints of the 
communication. 

2 There is no requirement to add: a hardware display, a 
hardware keyboard, or hardware to support the ability to 
connect to a display or keyboard, wired or wirelessly, if this 
hardware would not normally be provided. 

3 For the purposes of interoperability, 
Recommendation ITU-T T.140 is widely used. 

4 When an Indian language setting is selected by the user, the 
text shall also be in the same language as the language of the 
voice. 


support of 


5 Feature phones may not be able to support RTT capabilities. 


6.2.1.2 Concurrent voice and text 


Where ICT provides a means for two-way voice 
communication and for users to communicate by RTT, 
it shall allow concurrent voice and text through a single 
user connection. 


NOTES 


1 With many-party communication, as in a conference system, 
it is allowed (but not required or necessarily recommended) that 
RTT be handled in a single display field and that “‘turn-taking” be 
necessary to avoid confusion (in the same way that turn-taking is 
required for those presenting/talking with voice). 

2 With many-party communication, best practice is for hand- 
raising for voice users and RTT users to be handled in the same 
way, so that voice and RTT users are in the same queue. 


3 With a many-party conference system that has chat as one 
of its features - the RTT (like the voice) would typically be 
separate from the chat so that RTT use does not interfere with 
chat (that is, people can be messaging in the chat field while the 
person is presenting/talking with RTT-in the same manner that 
people message using the chat feature while people are talking 
with voice). RTT users would then use RTT for presenting and 
use the chat feature to message while others are presenting 
(via voice or RTT). 

4 The availability of voice and RTT running concurrently (and 
separately from chat) can also allow the RTT field to support 
text captioning when someone is speaking (and it is therefore 
not being used for RTT since it is not the RTT user’s turn to 
speak). 

5 Where both server-side software and local hardware and 
software are required to provide voice communication, 
where neither part can support voice communication without 
the other and are sold as a unit for the voice communication 
function, the local and server-side components are considered 
a single product. 

6 Whenever the speech, RTT and Chat are taking place, it is 
desirable to provide text in the same Indian language supported 
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and chosen by the user for speech, unless it is agreed to by 
convention or by an understanding prior to the conversation 
that a common language will be used for text and chat, that 
may not be the spoken language of the users. 


6.2.2 Display of RTT 


6.2.2.1 Visually distinguishable display 


Where ICT has RTT display for send and receive 
capabilities, the sent text shall be visually differentiated 
from, and separated from, received text. 


NOTES 


1 The ability of the user to choose between having the send and 
receive text be displayed in-line or separately, and with options 
to select, allows users to display RTT in a form that works best 
for them. This would allow Braille users to use a single field 
and take turns and have text appear in the sequential way that 
they may need or prefer. 


2 Whenever the desired Indian language of the user is offered, 
the language chosen by the user shall be preserved in the 
display, unless the sender and receiver agree to use a common 
language for the RTT. 


6.2.2.2 Programmatically determinable send and 
receive direction 


Where ICT has RTT send and receive capabilities, the 
send/receive direction of transmitted/received text shall 
be programmatically determinable, unless the RTT is 
implemented as closed functionality. 


NOTES 
1 This enables screen readers to distinguish between incoming 
text and outgoing text when used with RTT functionality. 


2 Where one or more desired Indian languages of the user 
are offered, the function of programmatically determining 
the language of the text by the sender and receiver shall be 
provided for better coordination of communication. 


6.2.2.3 Speaker identification 


Where ICT has RTT capabilities, and provides speaker 
identification for voice, the ICT shall provide speaker 
identification for RTT. 


NOTES 

1 This is necessary to enable both voice and RTT participants 
to know who is currently communicating, whether it be in RTT 
or voice. 

2 Whenever the desired Indian language of the user is offered, 
speaker identification for RTT shall be in the chosen Indian 
language of the user. 


6.2.2.4 Visual indicator of Audio with RTT 


Where ICT provides two-way voice communication, and 
has RTT capabilities, the ICT shall provide a real-time 
visual indicator of audio activity on the display. 


NOTES 


The visual indicator may be a simple character position on 
the display that flickers on and off to reflect audio activity, or 
presentation of the information in another way that can be both 
visible to sighted users and passed on to deaf-blind users who 
are using a braille display. 

2 Without this indication a person who lacks the ability to hear 
does not know when someone is talking. 


6.2.3 Interoperability 


Where ICT with RTT functionality interoperates 
with other ICT with RTT functionality (as required 
by 6.2.1.1) they shall support the applicable RTT 
interoperability mechanisms described below: 


a) ICT interoperating with other ICT directly 
connected to the Public Switched Telephone 
Network (PSTN), using Recommendation ITU-T 
V.18 or any of its annexes for text telephony 
signals at the PSTN interface; 


ICT interoperating with other ICT using VOIP 
with Session Initiation Protocol (SIP) and using 
RTT that conforms to IETF RFC 4103. For 
ICT interoperating with other ICT using the IP 
Multimedia Sub-System (IMS) to implement 
VOIP, the set of protocols specified in ETSI TS 
126 114, ETSI TS 122 173 and ETSI TS 134 229 
describe how IETF RFC 4103 would apply; 


ICT interoperating with other ICT using 
technologies other than a or b, above, using a 
relevant and applicable common specification for 
RTT exchange that is published and available for 
the environments in which they will be operating. 
This common specification shall include a method 
for indicating loss or corruption of characters; and 


b) 


c) 


d) ICT interoperating with other ICT using a standard 
for RTT that has been introduced for use in any of 
the above environments, and is supported by all of 
the other active ICT that support voice and RTT in 


that environment. 
NOTES 


1 In practice, new standards are introduced as an alternative 
codec/protocol that is supported alongside the existing 
common standard and used when all end-to-end components 
support it while technology development, combined with other 
reasons including societal development and cost efficiency, 
may make others become obsolete. 


2 Where multiple technologies are used to provide voice 
communication, multiple interoperability mechanisms may be 
needed to ensure that all users are able to use RTT. 

Example — A conferencing system that supports voice 
communication through an internet connection might provide 
RTT over an internet connection using a proprietary RTT 
method (option c). However, regardless of whether the RTT 
method is proprietary or non-proprietary, if the conferencing 
system also offers telephony communication it will also need 
to support options a or b to ensure that RTT is supported over 
the telephony connection. 


6.2.4 RTT Responsiveness 


Where ICT utilises RTT input, that RTT input shall be 
transmitted to the ICT network or platform on which 
the ICT runs within 500ms of the time that the smallest 
reliably composed unit of text entry is available to 
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the ICT for transmission. Delays due to platform or 
network performance shall not be included in the 
500 ms limit. 


NOTES 


1 For character-by-character input, the “smallest reliably 
composed unit of text entry” would be a character. 


2 For word prediction it would be a word. For some voice 
recognition systems-the text may not exit the recognition 
software until an entire word (or phrase) has been spoken. 
In this case, the smallest reliably composed unit of text entry 
available to the ICT would be the word (or phrase). 


3 The 500 ms limit allows buffering of characters for this period 
before transmission so character by character transmission is 
not required unless the characters are generated more slowly 
than 1 per 500 ms. 


4 A delay of 300 ms, or less, produces a better impression of 
flow to the user. 


6.3 Caller ID 


Where ICT provides caller identification or similar 
telecommunications functions, the caller identification 
and similar telecommunications functions shall be 
available in text form as well as being programmatically 
determinable, unless the functionality is closed. 

NOTE — Whenever the desired Indian language of the user is 


offered, Caller ID shall also be in the Indian language chosen 
by the user. 


6.4 Alternatives to Voice-based Services 


Where ICT provides real-time voice-based 
communication and also provides voice mail, 
auto-attendant, or interactive voice response facilities, 
the ICT shall offer users a means to access the 
information and carry out the tasks provided by the ICT 
without the use of hearing or speech. 


NOTES 

1 Tasks that involve both operating the interface and perceiving 
the information would require that both the interface and 
information be accessible without use of speech or hearing. 
2 Solutions capable of handling audio, RTT and video 
media could satisfy the above requirement. 


3 Solutions shall preferably use the same Indian language 
chosen by the user, be it audio or text. 


6.5 Video Communication 


6.5.1 General (Informative) 


Clause 6.5 (video communications) provides 
performance requirements that support users who 
communicate using sign language and lip-reading. For 
these users, good usability is achieved with a resolution 
of at least Quarter Video Graphics Array (QVGA, 
320 x 240), a frame rate of 20 frames per second and 
over, with a time difference between speech audio and 
video that does not exceed 100 ms. 
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Increasing the resolution and frame rate further 
improves both sign language (especially finger spelling) 
and lip reading, with frame rate being more important 
than resolution. 


Time differences between audio and video 
(asynchronicity) can have a great impact on 
lip-reading-with video that lags behind audio having 
greater negative effect. 


End-to-end latency can be a problem in video (sign) 
communication. Overall delay values below 400 ms 
are preferred, with an increase in preference down to 
100 ms. Overall delay depends on multiple factors, 
including for example, network delay and video 
processing. For this reason, a testable requirement on 
minimum values for overall delay cannot be produced. 


NOTES 


1 Recommendation ITU-T F.703 defines and gives 
requirements for total conversation that relate to the integration 
of audio, RTT and video in a single user connection. 


2 Indian sign language shall only be used in conformance to 
MoI&B accessibility standard. 


3 Often, network capabilities, especially in rural areas and with 
mobile or 2G usage, can pose challenges making it difficult to 
meet these performance requirements. In such cases, alternate 
means, such as captioning or sub-titling may be used. 


6.5.2 Resolution 


Where ICT that provides two-way voice communication 
includes real-time video functionality, the ICT: 


a) shall support at least QVGA resolution; and 
b) should preferably support at least VGA resolution. 


6.5.3 Frame Rate 


Where ICT that provides two-way voice communication 
includes real-time video functionality, the ICT: 


a) shall support a frame rate of at least 20 frames per 
second (FPS); and 


b) should preferably support a frame rate of at least 
30 Frames Per Second (FPS) with or without sign 
language in the video stream. 


6.5.4 Synchronization between Audio and Video 


Where ICT that provides two-way voice communication 
includes real-time video functionality, the ICT shall 
ensure a maximum time difference of 100 ms between 
the speech and video presented to the user. 


NOTE — Recent research shows that, if audio leads the video, 
the intelligibility suffers much more than the reverse. 


6.5.5 Visual Indicator of Audio with Video 


Where ICT provides two-way voice communication, 
and includes real-time video functionality, the ICT shall 
provide a real-time visual indicator of audio activity. 


NOTES 


1 The visual indicator may be a simple visual dot or LED, 
or other type of on/off indicator that flickers to reflect audio 
activity. 
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2 Without this indication a person who lacks the ability to hear 
does not know when someone is talking. 


6.5.6 Speaker Identification with Video (Sign Language) 
Communication 


Where ICT provides speaker identification for voice 
users, it shall provide a means for speaker identification 
for real- time signing and sign language users once the 
start of signing has been indicated. 


NOTES 


1 The speaker ID can be in the same location as for voice users 
for multiparty calls. 


2 This mechanism might be triggered manually by a user, or 
automatically where this is technically achievable. 


3 Display of speaker ID in Sign Language shall conform to 
Indian Sign Language (ISL). 


6.6 Alternatives to Video-based Services 


Where ICT provides real-time video-based 
communication and also provides answering machine, 
auto attendant or interactive response facilities, the ICT 
should offer users a means to access the information 
and carry out the tasks related to these facilities for: 


a) audible information, without the use of hearing; 
b) spoken commands, without the use of speech; and 


c) visual information, without the use of vision. 
NOTES 
1 Solutions capable of generating real-time captions or 
handling RTT could satisfy the above requirement. 


2 Solutions supporting Indian languages, shall offer captions in 
the same Indian language supported and chosen by the user and 
shall be as per this standard. 


7 ICT WITH VIDEO CAPABILITIES 


7.1 Caption Processing Technology 


7.1.1 Captioning Playback 


Where ICT displays video with synchronized audio, it 
shall have a mode of operation to display the available 
captions. Where closed captions are provided as part of 
the content, the ICT shall allow the user to choose to 
display the captions. 


NOTES 


1 Captions may contain information about timing, colour and 
positioning. This caption data is necessary for caption users. 
Timing is used for caption synchronization. Colour can be 
used for speaker identification. Position can be used to avoid 
obscuring important information. 

2 If a Braille device is connected, the ICT should provide an 
option to display captions on the Braille device. 

3 Clause 7.1.1 refers to the ability of the player to display 
captions. Clauses 9.1.2.2, 10.1.2.2 and 11.1.2.2 refer to the 
provision of captions for the content (the video). 

4 Captioning and sub-titling shall preferably be in the same 
Indian language chosen by the user or in the language agreed 
to by all participants. 

5 Captioning shall be as per the Mol & B Accessibility 
standard. 


7.1.2 Captioning Synchronization 


Where ICT displays captions, the mechanism to display 
captions shall preserve synchronization between the 
audio and the corresponding captions as follows: 


a) Captions in recorded material: within 100 ms of 
the time stamp of the caption; and 


b) Live captions: within 100 ms of the availability of 
the caption to the player. 


7.1.3 Preservation of Captioning 


Where ICT transmits, converts or records video with 
synchronized audio, it shall preserve caption data such 
that it can be displayed in a manner consistent with 
7.1.1 and 7.1.2. 


Additional presentational aspects of the text such as 
screen position, text colours, text style and text fonts 
may convey meaning, based on regional conventions. 
Altering these presentational aspects could change the 
meaning and should be avoided wherever possible. 


7.1.4 Captions’ Characteristics 


Where ICT displays captions, it shall provide a way 
for the user to adapt the displayed characteristics of 
captions to their individual requirements, except where 
the captions are displayed as unmodifiable characters. 


NOTES 

1 Defining the background and foreground colour of subtitles, 
font type, size opacity of the background box of subtitles, and 
the contour or border of the fonts can contribute to meeting this 
requirement. 

2 Subtitles that are bitmap images are examples of unmodifiable 
characters. 

3 Characteristics of Captions and subtitles shall be as per the 
Mol&B accessibility standard and, where Indian language is 
offered, shall be in the same language chosen by the user. 


7.1.5 Spoken Subtitles 


Where ICT displays video with synchronized 
audio, it shall have a mode of operation to provide 
a spoken output of the available captions, except 
where the content of the displayed captions is not 
programmatically determinable. 


NOTES 


1 Being able to manage speech output range for spoken 
subtitles independently from general ICT speech is preferable 
for most users. That is possible when the audio file with spoken 
subtitle is delivered in a separate audio track and mixed in the 
end users’ device. 


2 Presenting the separate audio track with spoken subtitles in 
synchronization with the displayed subtitles/captions improves 
understandability of the subtitles. 

3 Providing subtitles/captions as separate text-streams, 
facilitates converting the respective texts into audio. 

4 Subtitles that are bitmap images are examples where the 
content of the displayed captions will not be programmatically 
determinable. 
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7.2 Audio Description Technology 


7.2.1 Audio Description Playback 


Where ICT displays video with synchronized audio, it 
shall provide a mechanism to select and play available 
audio description to the default audio channel. 


Where video technologies do not have explicit and 
separate mechanisms for audio description, an ICT is 
deemed to satisfy this requirement if the ICT enables 
the user to select and play several audio tracks. 


NOTES 
1 In such cases, the video content can include the audio 
description as one of the available audio tracks. 


2 Audio descriptions in digital media sometimes include 
information to allow descriptions that are longer than the gaps 
between dialogue. Support in digital media players for this 
“extended audio description” feature is useful, especially for 
digital media that is viewed personally. 


3 Where Indian language is offered, the audio descriptions shall 
be in the same Indian language supported by the system and 
chosen by the user. 


7.2.2 Audio Description Synchronization 


Where ICT has a mechanism to play audio description, 
it shall preserve the synchronization between the 
audio/visual content and the corresponding audio 
description. 


7.2.3 Preservation of Audio Description 


Where ICT transmits, converts, or records video with 
synchronized audio, it shall preserve audio description 
data such that it can be played in a manner consistent 
with 7.2.1 and 7.2.2. 


7.3 User Controls for Captions and Audio Description 


Where ICT primarily displays materials containing 
video with associated audio content, user controls 
to activate subtitling and audio description shall be 
provided to the user at the same level of interaction 
(that is, the number of steps to complete the task) as the 
primary media controls. 


NOTES 


1 Primary media controls are the set of controls that the user 
most commonly uses to control media. 

2 Products that have a general hardware volume control, such 
as a telephone, or a laptop which can be configured to display 
video through software but which is not its primary purpose, 
would not need dedicated hardware controls for captions and 
descriptions; however, software controls, or hardware controls 
mapped through software, would need to be at the same level 
of interaction. 

3 It is best practice for ICT to include additional controls 
enabling the user to select whether captions and audio 
description are turned on or off by default. 

4 Where Indian language is offered, user controls for captions 
and audio description shall be in the same language supported 
by the system and chosen by the user. 
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8 HARDWARE 


8.1 General 


8.1.1 Generic Requirements 


The “generic requirements” of clause 5 also apply to 
ICT that is hardware. 


NOTES 


1 Ability to input Indian language content and display Indian 
language content shall be provided in devices, especially 
desktops, laptops, notebooks, display boards, ATM’s, kiosks, 
digital sign boards, and mobile devices (source IS/ISO/IEC 
14496-22 : 2019, IS 16350 : 2016). 


2 Choice of fonts considered appropriate for Indian languages 
for accessibility shall be offered for users with accessibility 
needs (source IS/ISO/IEC 14496-22 : 2019) 


3 For website, SAKAL BHARATI font or similar font 
having same height and stem width for all Indian script is 
recommended. 


8.1.2 Standard Connections 


Where an ICT provides user input or output device 
connection points, the ICT shall provide at least one 
input and/or output connection that conforms to an 
industry standard non-proprietary format, directly or 
through the use of commercially available adapters. 


NOTES 


1 The intent of this requirement is to ensure compatibility 
with assistive technologies by requiring the use of standard 
connections on ICT. 


2 The word connection applies to both physical and wireless 
connections. 


3 Current examples of industry standard non-proprietary 
formats are USB and Bluetooth. 


8.1.3 Colour 


Where the ICT has hardware aspects that use colour, 
colour shall not be used as the only visual means of 
conveying information, indicating an action, prompting 
a response, or distinguishing a visual element. 


8.2 Hardware Products with Speech Output 
8.2.1 Speech Volume Gain 


8.2.1.1 Speech volume range 


Where ICT hardware has speech output, it shall provide 
a means to adjust the speech output volume level over 
a range of at least 18dB. 

NOTE — Fixed-line handsets and headsets fulfilling the 


requirements of ANSI/TIA-4965 are deemed to comply with 
this requirement. 


8.2.1.2 Incremental volume control 


Where ICT hardware has speech output and its 
volume control is incremental, it shall provide at least 
one intermediate step of 12dB gain above the lowest 
volume setting. 
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8.2.2 Magnetic Coupling 
8.2.2.1 Fixed-line devices 


Where ICT hardware is a fixed-line communication 
device with speech output and which is normally 
held to the ear, it shall provide a means of magnetic 
coupling which meets the requirements of ETSI ES 
200381-1andshallcarrythe“T”’symbolspecifiedinETSI 
ETS 300 381. 


NOTES 


1 ICT fulfilling the requirements of TIA-1083-A is deemed to 
comply with the requirements of this clause. 


2 Magnetic coupling is also known as inductive coupling for 
T-coil.” 


8.2.2.2 Wireless communication devices 


Where ICT hardware is a wireless communication 
device with speech output which is normally held to 
the ear, it shall provide a means of magnetic coupling 
to hearing technologies which meets the requirements 
of ETSI ES 200 381-2. 


NOTE — ICT fulfilling the requirements of ANSI/IEEE 
C63.19 is deemed to comply with the requirements of this 
clause. 


8.3 Stationary ICT 
8.3.0 General 


This standard defines the dimensions for accessing 
stationary ICT that can be placed in a built environment 
but does not define the dimensions of the built 
environment in general. 


The scope includes stationary ICT, of which floors 
and circulation spaces are “an integral part” (typically 
kiosks and cabins), and where there are external reach 
ranges relevant for operating the stationary ICT. 


8.3.1 Forward or Side Reach 


Stationary ICT shall conform to either 8.3.2 or 8.3.3. 
NOTES 


1 This does not preclude conforming to both clauses. 


2 Physical access to stationary ICT is dependent on the 
dimensions of both the ICT and the environment in which 
it is installed and operated. Clause 8.3 does not apply to the 
accessibility of the physical environment external to the ICT. 


3) The dimensions specified in the Harmonized Guidelines 
and Space Standards for Barrier-Free Built Environment for 
persons with Disability and Elderly Persons, Feb-16 to be 
referred. 


8.3.2 Forward Reach 


8.3.2.1 Unobstructed high forward reach 


Where no part of the stationary ICT obstructs the 
forward reach, at least one of each type of operable 
part shall be located no higher than 1200 mm 
above the floor of the access space. This is shown 
in Fig. 2. 


8.3.2.2 Unobstructed low forward reach 


Where no part of the stationary ICT obstructs the 
forward reach, at least one of each type of operable part 
shall be located no lower than 380 mm above the floor 
of the access space. This is shown in Fig. 2. 


8.3.2.3 Obstructed forward reach 
8.3.2.3.1 Clear space 


Where an obstruction is an integral part of the stationary 
ICT and hinders the access to any type of operable 
part, the ICT shall provide a clear space which extends 
beneath the obstructing element for a distance not less 
than the required reach depth over the obstruction. 
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NOTE — Ensuring that there will be unhindered “access to 
any type of operable part” guarantees that a user will be able 
access at least one of each type of operable part. 


8.3.2.3.2 Obstructed (< 500 mm forward reach) 


Where the stationary ICT has an obstruction, which 
is an integral part of the ICT and which is less than 
500 mm, the forward reach to at least one of each type of 
operable part shall be no higher than 1000 mm above the 
floor contact of the ICT. This is shown in Fig. 3 (a). 


8.3.2.3.3 Obstructed (< 600 mm forward reach) 


Where the stationary ICT has an obstruction, which is 
an integral part of the ICT and which is not less than 
500 mm but is less than 600 mm maximum, the forward 
reach to at least one of each type of operable part shall be 
no higher than 1100 mm above the floor contact of the 
ICT. This is shown in Fig. 3 (b). 


AAMAS 
380 min 


1200 max 


Fic. 2 UNOBSTRUCTED FORWARD REACH 


1000 max 


> 500 - 600 max 


1100 max 


Fic. 3 OBSTRUCTED FORWARD REACH 
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8.3.2.4 Knee and toe clearance width 


Where the space under an obstacle that is an integral 
part of the stationary ICT is part of access space, the 
clearance shall be at least 900 mm wide. 


8.3.2.5 Toe clearance 
Where an obstacle is an integral part of the stationary 


ICT, a space under the obstacle that is less than 230 mm 
above the floor is considered toe clearance and shall: 


a) extend 635 mm maximum under the whole 
obstacle; 

b) provide a space at least 430 mm deep and 230 mm 
above the floor under the obstacle; and 


c) extend no more than 150 mm beyond any 
obstruction at 230 mm above the floor. This is 
shown in Fig. 4. 


150 max 


(a) 


elevation 


8.3.2.6 Knee clearance 


Where an obstacle is an integral part of the stationary 
ICT, the space under the obstacle that is between 
230 mm and 685 mm above the floor is considered knee 
clearance and shall: 


a) extend no more than 635 mm under the obstacle at 
a height of 230 mm above the floor; 

b) extend at least 280 mm under the obstacle at a 
height of 230 mm above the floor; 

c) extend at least 205 mm under the obstacle at a 
height of 685 mm above the floor; and 


d) be permitted to be reduced in depth at a rate of 
25 mm for each 150 mm in height. 


This is shown in Fig. 5. 


760 min 


430-635 


FIG.4 TOE CLEARANCE 


280 min / 


(a) 


elevation 


760 min 


Fic. 5 KNEE CLEARANCE 
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8.3.3 Side Reach 
8.3.3.1 Unobstructed high side reach 


Where the side reach is unobstructed or obstructed 
by an element that is an integral part of the stationary 
ICT and which is less than 255 mm, at least one of 
each type of operable part shall be within a high side 
reach which is less than or equal to 1 220 mm above 
the floor of the access space. This is shown in Fig. 6. 


8.3.3.2 Unobstructed low side reach 


Where the side reach is unobstructed or obstructed 
by an element that is an integral part of the stationary 
ICT and which is less than 255 mm, at least one of 
each type of operable part shall be within a low side 
reach which is greater than or equal to 380 mm above 
the floor of the access space. This is shown in Fig. 6. 


8.3.3.3 Obstructed side reach 
8.3.3.3.1 Obstructed (< 255 mm) side reach 


Where stationary ICT has an obstruction, which is an 
integral part of the ICT, the height of the obstruction 
shall be less than 865 mm. Where the depth of the 
obstruction is less than or equal to 255 mm, the high 
side each to at least one of each type of operable part 
shall be no higher than 1 220 mm above the floor of 
the access space. This is shown in Fig. 7 (a). 


8.3.3.3.2 Obstructed (< 610 mm) side reach 


Where stationary ICT has an obstruction, which is an 
integral part of the ICT, the height of the obstruction 
shall be less than 865 mm. Where the depth of the 
obstruction is greater than 255 mm with a maximum 
depth of 610 mm, the high side reach to at least one 
of each type of operable part shall be no higher than 
1170 mm above the floor of the access space. This is 
shown in Fig. 7 (b). 


SISSON 
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8.3.4 Clear Floor or Ground Space 


8.3.4.1 Change in level 


Where stationary ICT has a floor within it, then any 
change of floor level within it or entering it shall be 
ramped with a slope no steeper than | : 12. 


Exceptions: 


If the change in floor level is less than or equal to 6, 
4 mm (4 inch) the change may be vertical as shown in 
Fig. 8. 


If the change in floor level is less than or equal to 
13 mm (% inch) the change may have a slope not 
steeper than 1:2 as shown in Fig. 9. 


8.3.4.2 Clear floor or ground space 


Where stationary ICT has an operating area within it, 
it shall provide a clear floor area that has the minimum 
dimensions of 900 mm by 1 200 mm from which to 
operate the ICT. This is shown in Fig 10. 


8.3.4.3 Approach 
8.3.4.3.1 General 


Where stationary ICT has an access space inside it, at 
least one full side of the space shall be unobstructed. 


8.3.4.4 Forward approach 


Where the operating area is inside an alcove within the 
stationary ICT, the alcove is deeper than 610 mm, and 
where a forward approach is necessary, the dimension 
of the access space shall be a minimum of 915 mm 
wide. This is shown in Fig.11. 


8.3.4.5 Parallel approach 


Where the operating area is inside an alcove within the 
stationary ICT, the alcove is deeper than 380 mm, and 
where a parallel approach is possible, the dimension of 
the access space shall be a minimum of 1525 mm wide. 
This is shown in Fig. 12. 


380 
1220 max 


Fic. 6 UNOBSTRUCTED SIDE REACH 
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865 max 


| 
>255 - 610 max / 


(b) 


(a) 


FIG. 7 OBSTRUCTED HIGH SIDE REACH (EN) 


6.4 max 


A —— 


FIG. 8 VERTICAL CHANGE İN LEVEL 


6.4 mm 


13 


mm 


Ae 
— 


6.4 mm. çe 


FIG.9 BEVELLED CHANGE İN LEVEL 


1200 min 


900 min 


Fic. 10 CLEAR FLOOR OR GROUND SPACE 
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1525 min 


Fic. 12 MANOEUVRING CLEARANCE IN AN ALCOVE, PARALLEL APPROACH 


8.3.5 Visibility 


Where stationary ICT provides one or more display 
screens, at least one of each type of display screen shall 
be positioned such that the information on the screen is 
legible from a point located 1015 mm above the centre 
of the floor of the operating area). 

NOTE — The intent of this requirement is that the information 


on the screen can be read by users with normal vision and 
appropriate language skills, when seated in a wheelchair. 


8.3.6 Installation Instructions 


Installation instructions shall be made available for all 
stationary ICT. These instructions shall give guidance 
on how to install the ICT in a manner that takes into 
account applicable requirements for accessibility of 
the built environment as they apply to the installation 
of the ICT. Where there are no such requirements the 
instructions should require that the dimensions of the 
installed ICT conform to 8.3.2 to 8.3.5 of this standard. 
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8.4 Mechanically Operable Parts 
8.4.1 Numeric Keys 


Where provided, physical numeric keys arranged in a 
rectangular keypad layout shall have the number five 
key tactilely distinct from the other keys of the keypad. 


NOTES 


1 Recommendation ITU-T E.161 describes the 12-key 
telephone keypad layout and provides further details of the 
form of tactile markers. 

2 Where soft key based keyboard is used in public terminals 
like petrol pumps, PoS terminals and the like - as is becoming 
increasingly common, provision may be made for an alternate 
way of location and navigation within the key board space 
to assist the user about the keys such as through provision of 
audio - also ensuring privacy through headphone support while 
entering privacy respecting input. 
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8.4.2 Operation of Mechanical Parts 


8.4.2.1 Means of operation of mechanical parts 


Where a control requires grasping, pinching, or twisting 
of the wrist to operate it, an accessible alternative 
means of operation that does not require these actions 
shall be provided. 


8.4.2.2 Force of operation of mechanical parts 


Where a control requires a force greater than 22.2 N to 
operate it, an accessible alternative means of operation 
that requires a force less than 22.2 N shall be provided. 

NOTE— ISO 21542: 2011 Building Construction-Accessibility 


and Usability of the Built Environment recommends a value 
between 2.5 and 5 Newtons. 


8.4.3 Keys, Tickets and Fare Cards 


Where ICT provides keys, tickets or fare cards, and 
their orientation is important for further use, they shall 
have an orientation that is tactilely discernible. 


NOTE— ETSIETS 300 767 defines suitable tactile indications 
for plastic cards. 


8.5 Tactile Indication of Speech Mode 


Where ICT is designed for shared use and speech 
output is available, a tactile indication of the means to 
initiate the speech mode of operation shall be provided. 


NOTE — The tactile indication could include Braille 
instructions. 


9 WEB 


9.0 General (Informative) 


Requirements in 9 apply to web pages (as defined in 
3.1) including: 


a) Conformance with W3C Web Content 
Accessibility Guidelines (WCAG 2.0) Level AA 
is equivalent to conforming with clauses 9.1.1, 
9.1.2, 9.1.3.1 to 9.1.3.3, 9.1.4.1 to 9.1.4.5, 9.2.1.1, 
9.2.1.2, 9.2.2, 9.2.3, 9.2.4, 9.3, 9.4.1.1, 9.4.1.2 and 
the conformance requirements of 9.6 of of this 
standard. 

b) Conformance with W3C Web Content 

Accessibility Guidelines (WCAG 2.1) Level AA 

is equivalent to conforming with all of 9.1 to 9.4 

and the conformance requirements of 9.6 of this 

standard. 

c) Requirements for non-web documents and non-web 

software are given in 10 and 11 respectively. 


NOTE 


1 When evaluating web sites, they are evaluated as individual 
web pages. Web applications, including mobile web 
applications, are covered under the definition of web page 
which is quite broad and covers all web content types. 

2 WCAG 2.0 is identical to ISO/IEC 40500:2012: “Information 
technology-W3C Web Content Accessibility Guidelines 
(WCAG) 2.0”. 
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a) The requirements in 9.1 to 9.4 are written using the 
concept of satisfying success criteria (defined in 3.1). A 
web page satisfies a WCAG success criterion when the 
success criterion does not evaluate to false when applied to 
the web page. This implies that if the success criterion puts 
conditions on a specific feature and that specific feature does 
not occur in the web page, then the web page satisfies the 
success criterion. 


3 For example, a web page that does not contain pre-recorded 
audio content in synchronized media will automatically satisfy 
WCAG success criterion 1.2.2 (captions - pre-recorded) and, in 
consequence, will also conform to 9.1.2.2. 


a) In addition to Level AA success criteria, the web content 
accessibility guidelines also include success criteria for Level 
AAA. These are listed in 9.5 of this standard. Web authors 
and procurement accessibility specialists are encouraged 
to consider whether any of the WCAG Level AAA success 
criteria offer suggestions that may be applicable and relevant 
to their project, as well as potentially beneficial to some 
users. 


4 The W3C states that “It is not recommended that Level AAA 
conformance be required as a general policy for entire sites 
because it is not possible to satisfy all Level AAA success 
criteria for some content”. 


5 “Void” clauses have been inserted in order to maintain 
alignment with the numbering of WCAG 2.1 Level A and 
Level AA success criteria. 


6 Multilingual aspect of the web site must be considered in 
Indian context. The metadata related to accessibility services 
must also be created in at least one of the languages of the main 
content. If the website is multilingual, then corresponding 
multilingual metadata must also be provided. 


9.1 Perceivable 
9.1.1 Text Alternatives 


9.1.1.1 Non-text content 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.1.1 Non-text content. 


9.1.2 Time-based Media 


9.1.2.1 Audio-only and video-only (pre-recorded) 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.2.1 Audio-only and Video-only 
(Pre-recorded). 


9.1.2.2 Captions (pre-recorded) 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.2.2 Captions (Pre-recorded). 
9.1.2.3 Audio description or media alternative 
(pre-recorded) 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.2.3 Audio Description or Media 
Alternative (Pre-recorded). 


9.1.2.4 Captions (live) 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.2.4 Captions (Live). 


9.1.2.5 Audio description (pre-recorded) 


Where ICT is a web page, it shall satisfy WCAG 
2.1 Success Criterion 1.2.5 Audio Description 
(Pre-recorded). 


9.1.3 Adaptable 


9.1.3.1 Info and relationships 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.3.1 Info and Relationships. 

9.1.3.2 Meaningful sequence 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.3.2 Meaningful Sequence. 

9.1.3.3 Sensory characteristics 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.3.3 Sensory Characteristics. 
9.1.3.4 Orientation 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.3.4 Orientation. 

9.1.3.5 Identify input purpose 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.3.5 Identify Input Purpose. 

9.1.4 Distinguishable 


9.1.4.1 Use of colour 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.1 Use of Colour. 

9.1.4.2 Audio control 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.2 Audio Control. 

9.1.4.3 Contrast (minimum) 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.3 Contrast (Minimum). 

9.1.4.4 Resize text 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.4 Resize text. 

9.1.4.5 Images of text 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.5 Images of Text. 

9.1.4.6 Void 

9.1.4.7 Void 


9.1.4.8 Void 
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9.1.4.9 Void 


9.1.4.10 Reflow 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.10 Reflow. 

9.1.4.11 Non-text Contrast 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.11 Non-text Contrast. 

9.1.4.12 Text spacing 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.12 Text spacing. 


NOTE — For Indian languages, text spacing shall be as per the 
font standard specified (source IS/ISO/IEC 14496-22 : 2019). 


9.1.4.13 Content on hover or focus 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 1.4.13 Content on Hover or Focus. 
9.2 Operable 

9.2.1 Keyboard Accessible 


9.2.1.1 Keyboard 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.1.1 Keyboard. 


NOTE — In respect of Indian languages, keyboard layout may 
be as specified in the standard. 


9.2.1.2 No keyboard trap 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.1.2 No Keyboard Trap. 

9.2.1.3 Void 


9.2.1.4 Character key shortcuts 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.1.4 Character Key Shortcuts. 

9.2.2 Enough Time 


9.2.2.1 Timing adjustable 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.2.1 Timing Adjustable. 

9.2.2.2 Pause, stop, hide 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.2.2 Pause, Stop, Hide. 


9.2.3 Seizures and Physical Reactions 


9.2.3.1 Three flashes or below threshold 


Where ICT is a web page, it shall satisfy WCAG 
2.1 Success Criterion 2.3.1 Three Flashes or Below 
Threshold. 
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9.2.4 Navigable 


9.2.4.1 Bypass blocks 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.1 Bypass Blocks. 

9.2.4.2 Page titled 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.2 Page Titled. 

9.2.4.3 Focus order 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.3 Focus Order. 

9.2.4.4 Link purpose (in context) 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.4 Link Purpose (In Context). 
9.2.4.5 Multiple ways 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.5 Multiple Ways. 

9.2.4.6 Headings and labels 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.6 Headings and Labels. 

9.2.4.7 Focus visible 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.4.7 Focus Visible. 


9.2.5 Input Modalities 


9.2.5.1 Pointer gestures 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.5.1 Pointer Gestures. 

9.2.5.2 Pointer cancellation 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.5.2 Pointer Cancellation. 

9.2.5.3 Label in name 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.5.3 Label in Name. 

9.2.5.4 Motion actuation 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 2.5.4 Motion Actuation. 

9.3 Understandable 

9.3.1 Readable 


9.3.1.1 Language of page 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.1.1 Language of Page. 
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9.3.1.2 Language of parts 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.1.2 Language of Parts. 

9.3.2 Predictable 


9.3.2.1 On focus 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.2.1 On Focus. 

9.3.2.2 On input 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.2.2 On Input. 

9.3.2.3 Consistent navigation 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.2.3 Consistent Navigation. 

9.3.2.4 Consistent identification 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.2.4 Consistent Identification. 


9.3.3 Input assistance 


9.3.3.1 Error identification 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.3.1 Error Identification. 

9.3.3.2 Labels or instructions 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.3.2 Labels or Instructions. 

9.3.3.3 Error suggestion 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 3.3.3 Error Suggestion. 

9.3.3.4 Error prevention (legal, financial, data) 


Where ICT is a web page, it shall satisfy WCAG 
2.1 Success Criterion 3.3.4 Error Prevention (Legal, 
Financial, Data). 


9.4 Robust 
9.4.1 Compatible 


9.4.1.1 Parsing 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 4.1.1 Parsing. 

9.4.1.2 Name, role, value 

Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 4.1.2 Name, Role, Value. 

9.4.1.3 Status messages 


Where ICT is a web page, it shall satisfy WCAG 2.1 
Success Criterion 4.1.3 Status Messages. 


9.5 WCAG 2.1 AAA Success Criteria 


In addition to the Level AA success criteria, included 
in 9.1 to 9.4, the web content accessibility guidelines 
include success criteria for Level AAA. These are listed 
in Table 2. Web authors and procurement accessibility 
specialists are encouraged to consider the WCAG 
2.1 Level AAA success criteria that, when it is possible 
to apply them, may provide access beyond that required 
in this Standard. 


NOTE — The W3C states that “It is not recommended that 
Level AAA conformance be required as a general policy for 
entire sites because it is not possible to satisfy all Level AAA 
Success Criteria for some content”. 
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9.6 WCAG Conformance Requirements 


Where ICT is a web page, it shall satisfy all the 
following five WCAG 2.1 conformance requirements 
at Level AA: 


a) Conformance level; 
b) Full pages; 
c) Complete processes; 


d) Only accessibility-supported ways of using 
technologies; and 


e) Non-interference. 


Table 2 WCAG 2.1 Level AAA Success Criteria 


( Clause 9.5 ) 


SI No. Guideline Success Criterion Number Success Criteria Name 
o) 2) (3) (4) 
i) Time-based media 126 Sign Language (Pre-recorded) 
ii) Time-based media 127 Extended Audio Description (Pre-recorded) 
iii) Time-based media 1.2.8 Media Alternative (Pre-recorded) 
iv) Time-based media 1.2.9 Audio-only (Live) 
v) Adaptable 1.3.6 Identify Purpose 
vi) Distinguishable 1.4.6 Contrast (Enhanced) 
vü) Distinguishable 14.7 Low or No Background Audio 
viii) Distinguishable 1.4.8 Visual Presentation 
ix) Distinguishable 1.4.9 Images of Text (No Exception) 
x) Keyboard Accessible 2.1.3 Keyboard (No Exception) 
xi) Enough time 203 No Timing 
xii) Enough time 2.2.4 Interruptions 
xiii) Enough time 22:5 Re-authenticating 
xiv) Enough time 2.2.6 Timeouts 
xv) Seizures and physical reactions 232 Three Flashes 
xvi) Seizures and physical reactions 235 Animation form Interactions 
xvii) O Navigable 2.4.8 Location 
xviii) Navigable 2.4.9 Link Purpose (Link Only) 
xix) Navigable 2.4.10 Section Headings 
xx) Input modalities 25.3 Target Size 
xxi) Input modalities 2.5.6 Concurrent Input Mechanisms 
xxii) Readable i Unusual Words 
xxiii) Readable 3.1.4 Abbreviations 
xxiv) Readable 3.9 Reading Level 
XXV) Readable 3.1.6 Pronunciation 
xxvi) Predictable 3.2.5 Change on Request 
xxvii) Input assistance 335 Help 
xxvili) Input assistance 3.3.6 Error Prevention (All) 
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NOTES 


1 Aweb page that meets all requirements of 9.1 to 9.4, or where 
a Level AA conforming alternate version (as defined in WCAG 
2.1) is provided, will meet conformance requirement 1. 

2 According to W3C: “WCAG 2.1 extends web content 
accessibility guidelines 2.0, which was published as a W3C 
Recommendation December 2008. Content that conforms to 
WCAG 2.1 also conforms to WCAG 2.0, and therefore to 
policies that reference WCAG 2.0”. 

3 Conformance requirement 5 states that all content on the 
page, including content that is not otherwise relied upon to 
meet conformance, meets clauses 9.1.4.2, 9.2.1.2, 9.2.2.2 and 
9.2.3.1. 


10 NON-WEB DOCUMENTS 


10.0 General (Informative) 
Requirements in 10 apply to: 
a) documents that are not web pages; 


b) documents that are not embedded in web pages; 
and 


c) documents that are provided with web pages but 
are neither embedded nor rendered together with 
the web page from which they are provided (that 
is, the present clause applies to downloadable 
documents). 


Clause 9 provides requirements for documents that are 
in web pages or that are embedded in web pages and 
that are used in the rendering or that are intended to be 
rendered together with the web page in which they are 
embedded. 


NOTES 


1 Some examples of documents are letters, spreadsheets, 
emails, books, pictures, presentations, and movies that have 
an associated user agent, such as a document reader, editor or 
media player. 

2 Asingle document may be composed of multiple files such as 
the video content and closed caption text. 

This fact is not usually apparent to the end-user consuming the 
document/content. 

3 Documents require a user agent in order for the content to 
be presented to users. The requirements for user agents can be 
found in 11. 


4 The requirements for content that is part of software, can be 
found in 11. 


5 The success criteria set out in 10 are intended to harmonize 
with the Working Group Note produced by the W3C’s 
WCAG2ICT Task Force. 


6 “Void” clauses have been inserted in order to maintain 
alignment of the numbering in 9, 10 and 11. 


7 Requirements in 10 also apply to documents that are protected 
using mechanisms, such as digital signatures, encryption, 
password protection, and watermarks when they are presented 
to the user. 

8 It is best practice to provide meta data on the accessibility 
of the document within or separate to the document using web 
schemas/accessibility 2.0. 

9 Documents in Indian languages shall be supported for 
accessibility (see 5.10). 
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10.1 Perceivable 
10.1.1 Text Alternatives 


10.1.1.1 Non-text content 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.1.1 Non-text Content. 


NOTE — CAPTCHAs do not currently appear outside of the 
Web. However, if they do appear, this guidance is accurate. 


10.1.2 Time-based Media 


10.1.2.1 Audio-only and video-only (pre-recorded) 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 1.2.1 Audio-only and 
Video-only (Pre-recorded). 


NOTE — The alternative can be provided directly in the 
document-or provided in an alternate version that meets the 
success criterion. 


10.1.2.2 Captions (pre-recorded) 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.2.2 Captions 
(Pre-recorded). 


NOTE — The WCAG 2.1 definition of “captions” notes that 
“in some countries, captions are called subtitles”. They are also 
sometimes referred to as “subtitles for the hearing impaired”. 
Per the definition in WCAG 2.1, to meet this success criterion, 
whether called captions or subtitles, they would have to provide 
“synchronized visual and/or text alternative for both speech 
and non-speech audio information needed to understand the 
media content” where non-speech information includes “sound 
effects, music, laughter, speaker identification and location”. 


10.1.2.3 Audio description or media alternative 
(pre-recorded) 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.2.3 Audio Description 
or Media Alternative (Pre-recorded). 


NOTES 


1 The WCAG 2.1 definition of “audio description” says that 
“audio description” is “Also called ‘video description’ and 
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‘descriptive narration’”. 


2 Secondary or alternate audio tracks are commonly used for 
this purpose. 


10.1.2.4 Captions (live) 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.2.4 Captions (Live). 


NOTE — The WCAG 2.1 definition of “captions” notes that 
“in some countries, captions are called subtitles”. They are also 
sometimes referred to as “subtitles for the hearing impaired”. 
Per the definition in WCAG 2.1, to meet this success criterion, 
whether called captions or subtitles, they would have to provide 
“synchronized visual and/or text alternative for both speech 
and non-speech audio information needed to understand the 
media content” where non-speech information includes “sound 
effects, music, laughter, speaker identification and location”. 


10.1.2.5 Audio description (pre-recorded) 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.2.5 Audio Description 
(Pre-recorded). 


NOTES 


1 The WCAG 2.1 definition of “audio description” says that 
audio description is “Also called ‘video description’ and 
‘descriptive narration””. 

2 Secondary or alternate audio tracks are commonly used for 
this purpose. 


10.1.3 Adaptable 
10.1.3.1 Info and relationships 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.3.1 Info and 
Relationships. 


NOTE — Where documents contain non-standard structure 
types (roles), it is best practice to map them to a standard 
structure type as a fall-back solution for the reader. 


10.1.3.2 Meaningful sequence 

Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.3.2 Meaningful 
Sequence. 

10.1.3.3 Sensory characteristics 

Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.3.3 Sensory 
Characteristics. 

10.1.3.4 Orientation 

Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.3.4 Orientation. 
10.1.3.5 Identify input purpose 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.3.5 Identify Input 
Purpose. 


10.1.4 Distinguishable 


10.1.4.1 Use of colour 

Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.4.1 Use of Colour. 
10.1.4.2 Audio control 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for Audio control: 


If any audio in a document plays automatically for 
more than 3 seconds, either a mechanism is available 
to pause or stop the audio, or a mechanism is available 
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to control audio volume independently from the overall 
system volume level. 


NOTES 


1 Since any part of a document that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
document, all content in the document (whether or not it is used 
to meet other success criteria) shall meet this success criterion. 
2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 1.4.2 Audio Control, replacing “on a Web page” with 
“in a document”, “any content” with “any part of a document”, 
“whole page” with “whole document”, “on the Web page” with 
“in the document”, removing “See Conformance Requirement 
5: Non-Interference” and adding note 1. 


10.1.4.3 Contrast (minimum) 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 1.4.3 Contrast 
(Minimum). 


10.1.4.4 Resize text 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.4.4 Resize Text. 


NOTES 

1 Content for which there are software players, viewers or 
editors with a 200 percent zoom feature would automatically 
meet this success criterion when used with such players, unless 
the content will not work with zoom. 

2 This success criterion is about the ability to allow users to 
enlarge the text on screen at least up to 200 percent without 
needing to use assistive technologies. This means that the 
application provides some means for enlarging the text 
200 percent (zoom or otherwise) without loss of content or 
functionality or that the application works with the platform 
features that meet this requirement. 

3 It is best practice to use only fonts that allow for scaling 
without loss of quality (for example, pixelized presentation). 
This applies in particular to embedded fonts. 


10.1.4.5 Images of text 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 1.4.5 Images of Text. 


10.1.4.6 Void 
10.1.4.7 Void 
10.1.4.8 Void 
10.1.4.9 Void 


10.1.4.10 Reflow 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


NOTE — Information originally contained in some tables 
where the table format was not informational in nature have 
been converted into text for better accessibility through screen 
readers. 
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Document success criterion for reflow 


Content can be presented without loss of information 
or functionality, and without requiring scrolling in two 
dimensions for: 


a) Vertical scrolling content at a width equivalent to 
320 CSS pixels; and 


b) Horizontal scrolling content at a height equivalent 
to 256 CSS pixels. 


Except for parts of the content which require two- 
dimensional layout for usage or meaning. 


NOTES 


1 320 CSS pixels is equivalent to a starting viewport width of 
1 280 CSS pixels wide at 400 percent zoom. For documents 
which are designed to scroll horizontally (for example, with 
vertical text), the 256 CSS pixels is equivalent to a starting 
viewport height of 1 024 pixels at 400 percent zoom. 


2 Examples of content which require two-dimensional layout 
are images, maps, diagrams, video, games, presentations, data 
tables, and interfaces where it is necessary to keep toolbars in 
view while manipulating content. 


3 This success criterion is identical to the WCAG 2.1 success 
criterion 1.4.10 Reflow replacing the original WCAG 2.1 notes 
with notes 1 and 2, above. 


10.1.4.11 Non-text contrast 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 1.4.11 Non-text Contrast. 


10.1.4.12 Text spacing 


Where ICT is a non-web document that does not have 
a fixed size content layout area that is essential to the 
information being conveyed, it shall satisfy WCAG 2.1 
Success Criterion 1.4.12 Text spacing. 


10.1.4.13 Content on hover or focus 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 1.4.13 Content on Hover 
or Focus. 


10.2 Operable 
10.2.1 Keyboard Accessible 


10.2.1.1 Keyboard 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 2.1.1 Keyboard. 


10.2.1.2 No keyboard traps 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for No keyboard trap: 


If keyboard focus can be moved to a component of 
the document using a keyboard interface, then focus 
can be moved away from that component using only 
a keyboard interface, and, if it requires more than 
unmodified arrow or tab keys or other standard exit 
methods, the user is advised of the method for moving 
focus away. 
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NOTES 


1 Since any part of a document that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
document, it is necessary for all content in the document 
(whether or not it is used to meet other success criteria) to meet 
this success criterion. 


2 Standard exit methods may vary by platform. For example, on 
many desktop platforms, the Escape key is a standard method 
for exiting. 

3 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.1.2 No Keyboard Trap replacing “page” and 
“Web page” with “document”, removing “See Conformance 
Requirement 5: Non-Interference” and with the addition of 
note 2 above and with note | above re-drafted to avoid the use 
of the word “must”. 


10.2.1.3 Void 


10.2.1.4 Character key shortcuts 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 2.1.4 Character Key 
Shortcuts. 


10.2.2 Enough Time 


10.2.2.1 Timing adjustable 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for Timing adjustable: 


For each time limit that is set by the document, at least 
one of the following is true: 


a) Turn off — The user is allowed to turn off the time 
limit before encountering it; 


b) Adjust — The user is allowed to adjust the time 
limit before encountering it over a wide range that 
is at least ten times the length of the default setting; 


c) Extend — The user is warned before time expires 
and given at least 20 s to extend the time limit with 
a simple action (for example, “press the space 
bar”), and the user is allowed to extend the time 
limit at least ten times; 


d) Real-time Exception — The time limit is a required 
part of a real-time event (for example, an auction), 
and no alternative to the time limit is possible; 


e) Essential Exception — The time limit is essential 
and extending it would invalidate the activity; or 


f) 20 Hour Exception — The time limit is longer than 
20 h. 
NOTES 


1 This success criterion helps ensure that users can complete 
tasks without unexpected changes in content or context that 
are a result of a time limit. This success criterion should be 
considered in conjunction with WCAG 2.1 Success Criterion 
3.2.1, which puts limits on changes of content or context as a 
result of user action. 

2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.2.1 Timing Adjustable replacing “the content” with 
“documents” and with the words “WCAG 2.1” added before 
the word “Success Criterion” in note 1 above. 


10.2.2.2 Pause, stop, hide 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion: Pause, stop, hide 


For moving, blinking, scrolling, or auto-updating 
information, all of the following are true: 


a) Moving, Blinking, Scrolling — For any moving, 
blinking or scrolling information that: 


1) starts automatically, 
2) lasts more than five seconds, and 


3) is presented in parallel with other content, 
there is a mechanism for the user to pause, 
stop, or hide it unless the movement, blinking, 
or scrolling is part of an activity where it is 
essential; and 


For 


b) Auto-updating 
information that: 


any auto-updating 


1) starts automatically; and 


2) is presented in parallel with other content, 
there is a mechanism for the user to pause, 
stop, or hide it or to control the frequency of 
the update unless the auto-updating is part of 
an activity where it is essential. 

NOTES 


1 For requirements related to flickering or flashing content, 
refer to WCAG 2.1 Guideline 2.3. 


2 Since any part of a document that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
document, it is necessary for all content in the document 
(whether it is used to meet other success criteria or not) to meet 
this success criterion. 

3 Content that is updated periodically by software or that 
is streamed to the user agent is not required to preserve or 
present information that is generated or received between the 
initiation of the pause and resuming presentation, as this may 
not be technically possible, and in many situations could be 
misleading to do so. 

4 An animation that occurs as part of a preload phase or similar 
situation can be considered essential if interaction cannot occur 
during that phase for all users and if not indicating progress 
could confuse users or cause them to think that content was 
frozen or broken. 

5 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.2.2 Pause, Stop, Hide replacing “page” and 
“Web page” with “document”, removing “See Conformance 
Requirement 5: Non-Interference” in note 2 of the success 
criterion, with the words “WCAG 2.1” added before the word 
“Guideline” in note 1 above and with note 2 above re-drafted 
to avoid the use of the word “must”. 


10.2.3 Seizures and Physical Reactions 


10.2.3.1 Three flashes or below threshold 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 
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Document success criterion for three flashes or 
below threshold: 


Documents do not contain anything that flashes more 
than three times in any one second period, or the flash is 
below the general flash and red flash thresholds. 


NOTES 


1 Since any part of a document that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
document, it is necessary for all content in the document 
(whether it is used to meet other success criteria or not) to meet 
this success criterion. 


2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.3.1 Three Flashes or Below Threshold replacing 
“Web pages” with “documents”, “the whole page” with “the 
whole document”, “the Web page” with “the document” 
and removing “See Conformance Requirement 5: Non- 
Interference” and with note | above re-drafted to avoid the use 
of the word “must”. 


10.2.4 Navigable 


10.2.4.1 Void 


NOTES 


1 The related web page requirement “Bypass blocks” does not 
apply to single documents, but to a specific definition of “sets 
of documents” that are rare. 


2 Although not a requirement, the ability to bypass blocks 
of content that are repeated within documents is generally 
considered best practice and addresses user needs. 


10.2.4.2 Document titled 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for Document titled: 


Documents have titles that describe topic or purpose. 
NOTES 


1 The name of a document (for example, document, media file) 
is a sufficient title if it describes the topic or purpose. 


2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.4.2 Page Titled replacing “Web pages” with 
“documents” and with the addition of note 1 above. 


10.2.4.3 Focus Order 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for focus order 


If a document can be navigated sequentially and the 
navigation sequences affect meaning or operation, 
focusable components receive focus in an order that 
preserves meaning and operability. 

NOTE — This success criterion is identical to the WCAG 2.1 


Success Criterion 2.4.3 Focus Order replacing “Web page” 
with “document”. 


10.2.4.4 Link purpose (in context) 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 2.4.4 Link Purpose (In 
Context). 
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10.2.4.5 Void 


NOTE — The related web page requirement “Multiple ways” 
does not apply to single documents, but to a specific definition 
of “sets of documents” that are rare. 


10.2.4.6 Headings and labels 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 2.4.6 Headings and 
Labels. 


10.2.4.7 Focus visible 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 2.4.7 Focus Visible. 


10.2.5 Input Modalities 


10.2.5.1 Pointer gestures 


Where ICT is a non-web document, it shall satisfy the 
success criterion as given below. 


Document success criterion for Pointer gestures: 


All functionality that uses multipoint or path-based 
gestures for operation can be operated with a single 
pointer without a path-based gesture, unless a multipoint 
or path-based gesture is essential. 


NOTES 


1 This requirement applies to documents that interpret pointer 
actions ( that is, this does not apply to actions that are required 
to operate the user agent or assistive technology). 


2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.5.1 Pointer Gestures replacing the original WCAG 
2.1 note with Note 1 above. 


10.2.5.2 Pointer cancellation 


Where ICT is a non-web document, it shall satisfy the 
success criterion as given below. 


Document success criterion for Pointer cancellation: 


For functionality that can be operated using a single 
pointer, at least one of the following is true: 


a) No Down-Event — The down-event of the pointer 
is not used to execute any part of the function; 


b) Abort or Undo — Completion of the function is 
on the up-event, and a mechanism is available to 
abort the function before completion or to undo 
the function after completion; 

c) Up Reversal — The up-event reverses any outcome 

of the preceding down-event; and 


d) Essential — Completing the function on the down- 
event is essential. 
NOTES 
1 Functions that emulate a keyboard or numeric keypad key 
press are considered essential. 


2 This requirement applies to a document that interprets pointer 
actions (that is, this does not apply to actions that are required 
to operate the user agent or assistive technology). 

3 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.5.2 Pointer Cancellation replacing the original 
WCAG 2.1 note with notes | and 2 above. 
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10.2.5.3 Label in name 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 2.5.3 Label in Name. 


10.2.5.4 Motion actuation 


Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 2.5.4 Motion Actuation. 


10.3 Understandable 
10.3.1 Readable 


10.3.1.1 Language of document 


Where ICT is a non-web document, it shall satisfy the 
Document success criterion as given below. 


Document success criterion for Language of document: 


The default human language of each document can be 
programmatically determined. 
NOTE — This success criterion is identical to the WCAG 


2.1 Success Criterion 3.1.1 Language of Page replacing “web 
page” with “document”. 


10.3.1.2 Language of parts 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for language of parts: 


The human language of each passage or phrase in 
the document can be programmatically determined 
except for proper names, technical terms, words of 
indeterminate language, and words or phrases that 
have become part of the vernacular of the immediately 
surrounding text. 


NOTES 


1 There are some document technologies where there is 
no assistive technology supported method for marking the 
language for the different passages or phrases in the document, 
and it would not be possible to meet this success criterion with 
those technologies. 

2 Inheritance is one common method. For example, a document 
provides the language that it is using and it can be assumed that 
all of the text or user interface elements within that document 
will be using the same language unless it is indicated. 

3 This success criterion is identical to the WCAG 2.1 Success 
Criterion 3.1.2 Language of Parts replacing “content” with 
“document” and with the addition of notes 1 and 2 above. 


10.3.2 Predictable 


10.3.2.1 Onfocus 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 3.2.1 On Focus. 


NOTE — Some compound documents and their user agents 
are designed to provide significantly different viewing and 
editing functionality depending upon what portion of the 
compound document is being interacted with (for example, 
a presentation that contains an embedded spreadsheet, where 
the menus and toolbars of the user agent change depending 
upon whether the user is interacting with the presentation 
content, or the embedded spreadsheet content). If the user uses 


a mechanism other than putting focus on that portion of the 
compound document with which they mean to interact (for 
example, by a menu choice or special keyboard gesture), any 
resulting change of context would not be subject to this success 
criterion because it was not caused by a change of focus. 


10.3.2.2 On input 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 3.2.2 On Input. 


10.3.2.3 Void 


NOTE — The related web page requirement “Consistent 
navigation” does not apply to single documents, but to a 
specific definition of “sets of documents” that are rare. 


10.3.2.4 Void 


NOTE — The related web page requirement “Consistent 
identification” does not apply to single documents, but to a 
specific definition of “sets of documents” that are rare. 


10.3.3 Input Assistance 


10.3.3.1 Error identification 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 3.3.1 Error Identification. 


10.3.3.2 Labels or instructions 


Where ICT is a non-web document, it shall satisfy 
the WCAG 2.1 Success Criterion 3.3.2 Labels or 
Instructions. 


10.3.3.3 Error suggestion 


Where ICT is a non-web document, it shall satisfy the 
WCAG 2.1 Success Criterion 3.3.3 Error Suggestion. 


10.3.3.4 Error prevention (legal, financial, data) 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for error prevention (legal, 
financial, data): 


For documents that cause legal commitments or 
financial transactions for the user to occur, that modify 
or delete user-controllable data in data storage systems, 
or that submit user test responses, at least one of the 
following is true: 


a) Reversible — Submissions are reversible. 


b) Checked — Data entered by the user is checked 
for input errors and the user is provided an 
opportunity to correct them. 


Confirmed — A mechanism is available for 
reviewing, confirming, and correcting information 
before finalizing the submission. 


NOTE — This success criterion is identical to the WCAG 2.1 
Success Criterion 3.3.4 Error Prevention (Legal, Financial, 
Data) replacing “web pages” with “documents”. 


10.4 Robust 
10.4.1 Compatible 
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10.4.1.1 Parsing 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for parsing: 


For documents that use markup languages, in such a 
way that the markup is separately exposed and available 
to assistive technologies and accessibility features of 
software or to a user-selectable user agent, elements 
have complete start and end tags, elements are nested 
according to their specifications, elements do not 
contain duplicate attributes, and any IDs are unique, 
except where the specifications allow these features. 


NOTES 


1 Start and end tags that are missing a critical character in their 
formation, such as a closing angle bracket or a mismatched 
attribute value quotation mark are not complete. 

2 Markup is not always available to assistive technology or 
to user selectable user agents such as browsers. In such cases, 
conformance to this [requirement] would have no impact on 
accessibility as it can for web content where it is exposed. 

3 Examples of markup that is separately exposed and available 
to assistive technologies and to user agents include but are not 
limited to: documents encoded in HTML, ODF, and OOXML. 
In these examples, the markup can be parsed entirely in two 
ways: (a) by assistive technologies which may directly open 
the document, (b) by assistive technologies using DOM APIs 
of user agents for these document formats. 

4 This success criterion is identical to the WCAG 2.1 Success 
Criterion 4.1.1 Parsing replacing “In content implemented 
using markup languages” with “For documents that use markup 
languages, in such a way that the markup is separately exposed 
and available to assistive technologies and accessibility 
features of software or to a user-selectable user agent” with the 
addition of Notes 2 and 3 above. 


10.4.1.2 Name, role, value 


Where ICT is a non-web document, it shall satisfy the 
document success criterion as given below. 


Document success criterion for name, role, value: 


For all user interface components (including but not 
limited to: form elements, links and components 
generated by scripts), the name and role can be 
programmatically determined; states, properties, 
and values that can be set by the user can be 
programmatically set; and notification of changes 
to these items is available to user agents, including 
assistive technologies. 


NOTES 


1 This success criterion is primarily for software developers 
who develop or use custom user interface components. 
Standard user interface components on most accessibility- 
supported platforms already meet this success criterion when 
used according to specification. 

2 For document formats that support interoperability with 
assistive technology, standard user interface components often 
meet this success criterion when used according to the general 
design and accessibility guidance for the document format. 

3 This success criterion is identical to the WCAG 2.1 success 
criterion 4.1.2 name, role, value replacing the original 
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WCAG 2.1 note with: “This success criterion is primarily for 
software developers who develop or use custom user interface 
components. For example, standard user interface components 
on most accessibility-supported platforms already meet this 
success criterion when used according to specification.” and 
with the addition of Note 2 above. 


10.4.1.3 Status messages 

Where ICT is a non-web document, it shall satisfy 
WCAG 2.1 Success Criterion 4.1.3 Status Messages. 
10.5 Caption Positioning 


Where ICT is a non-web document that contains 
synchronized media with captions, the captions should 
not obscure relevant information in the synchronized 
media. 


10.6 Audio Description Timing 


Where ICT is a non-web document that contains 
synchronized media with audio description, the audio 
description should not interfere with relevant audio 
information in the synchronized media. 


11 SOFTWARE 


11.0 General (Informative) 
This clause provides requirements for: 
a) platform software; 


b) software that provides a user interface including 


content that is in the software; 
c) authoring tools; 
d) 


e) 


software that operates as assistive technology; and 
mobile applications. 

NOTES 

1 User agents are examples of software that provide a 
user interface. They retrieve, render and facilitate end user 
interaction with authored content. User agents play a necessary 
role in the accessibility of authored content rendered in the 
user interface. UAAG 2.0 provides additional advice for those 
who are creating user agents and want to increase functionality 
when rendering authored content in an accessible way. 

2 The requirements for web content, including software that is 
web content, can be found in 9. 

3 The requirements for documents that may be presented by 
user agents, can be found in 10. 

4 Although the accessibility of command line interfaces is not 
dealt with in this standard, accessibility may be achieved by 
context specific requirements, some of which may be found in 
5 or 11. 


Requirements in clauses 11.1 to 11.5 apply to 
software: 


f 
g) 


that is not a web page; and 


not embedded in web pages nor used in the 
rendering or functioning of the page. 


Clause 9 provides requirements for software that is in 
web pages or that is embedded in web pages and that is 


38 


used in the rendering or that is intended to be rendered 
together with the web page in which it is embedded. 


Some requirements in 11.1 to 11.5 have different 
versions for open or closed functionality. In those 
cases, the corresponding clause will be divided into two 
sub-clauses. 


The success criteria set out in 11.1 to 11.5 are intended 
to harmonize with the W3C Working Group Note 
produced by the W3C’s WCAG2ICT Task Force. 


5 Software that provides a user interface includes its own 
content. Some examples of content in software include: the 
controls and text displayed in a menu bar of a graphical user 
interface application, images that appear in a toolbar, prompts 
spoken in an auditory user interface, other user interaction 
controls, and other text, graphics or material that is not loaded 
from outside the software. 


6 “Void” clauses have been inserted in order to maintain 
alignment of the numbering in clauses 9, 10 and 11. 


7 Indian language support may be provided for software 
developers and their development of user interfaces in Indian 
languages. Relevant clause of Section may also be referred to 
for details. 


11.1 Perceivable 
11.1.1 Text Alternatives 
11.1.1.1 Non-text content 


11.1.1.1.1 Non-text content (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy WCAG 
2.1 Success Criterion 1.1.1 Non-text Content. 


NOTE — CAPTCHAs do not currently appear outside of the 
Web. However, if they do appear, this guidance is accurate. 


11.1.1.1.2 Non-text content (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.6 
(speech output for non-text content). 


11.1.2 Time-based Media 
11.1.2.1 Audio-only and video-only (pre-recorded) 


11.1.2.1.1 Audio-only and video-only (pre-recorded- 
open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading and where pre-recorded 
auditory information is not needed to enable the use 
of closed functions of ICT, it shall satisfy the WCAG 
2.1 Success Criterion 1.2.1 Audio-only and Video-only 
(Pre-recorded). 

NOTE — The alternative can be provided directly in the 


software-or provided in an alternate version that meets the 
success criterion. 


11.1.2.1.2 Audio-only and video-only (pre-recorded- 
closed functionality) 


11.1.2.1.2.1 
functionality) 


Pre-recorded audio-only (closed 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies 
for screen reading and where pre-recorded auditory 
information is needed to enable the use of closed 
functions of ICT, the functionality of software that 
provides a user interface shall meet requirement 5.1.5 
(visual output for auditory information). 


11.1.2.1.2.2 
functionality) 


Pre-recorded  video-only (closed 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.7 
(speech output for video information). 


11.1.2.2 Captions (pre-recorded) 


Where ICT is non-web software that provides a user 

interface, it shall satisfy the WCAG 2.1 Success 

Criterion 1.2.2 Captions (Pre-recorded). 
NOTE — The WCAG 2.1 definition of “captions” notes that 
“in some countries, captions are called subtitles”. They are also 
sometimes referred to as “subtitles for the hearing impaired”. 
Per the definition in WCAG 2.1, to meet this success criterion, 
whether called captions or subtitles, they would have to provide 
“synchronized visual and / or text alternative for both speech 
and non-speech audio information needed to understand the 
media content” where non-speech information includes “sound 
effects, music, laughter, speaker identification and location”. 


111.2.3 Audio description or media alternative 
(pre-recorded) 


11.1.2.3.1 Audio description or media alternative 
(pre-recorded - open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy the 
WCAG 2.1 Success Criterion 1.2.3 Audio Description 
or Media Alternative (Pre-recorded). 


NOTES 


1 The WCAG 2.1 definition of “audio description” says that 
“audio description” is “also called ‘video description’ and 
‘descriptive narration””. 

2 Secondary or alternate audio tracks are commonly used for 
this purpose. 

3 If an Indian language has been chosen by the developer or 
is needed for fulfilling a user requirement of language, the 
alternative audio may also be in the same language. 


11.1.2.3.2 Audio description or media alternative 
(pre-recorded - closed functionality) 


Where ICT is non-web software that provides a user 
interface which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.7 
(speech output for video information). 
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11.1.2.4 Captions (live) 


Where ICT is non-web software that provides a user 

interface, it shall satisfy the WCAG 2.1 Success 

Criterion 1.2.4 Captions (Live). 
NOTE — The WCAG 2.1 definition of “captions” notes that 
“in some countries, captions are called subtitles”. They are also 
sometimes referred to as “subtitles for the hearing impaired”. 
Per the definition in WCAG 2.1, to meet this success criterion, 
whether called captions or subtitles, they would have to provide 
“synchronized visual and/or text alternative for both speech 
and non-speech audio information needed to understand the 
media content” where non-speech information includes “sound 
effects, music, laughter, speaker identification and location”. 


11.1.2.5 Audio description (pre-recorded) 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 1.2.5 Audio Description (Pre-recorded). 


NOTES 


1 The WCAG 2.1 definition of “audio description” says that 
audio description is “Also called ‘video description’ and 
‘descriptive narration’”. 

2 Secondary or alternate audio tracks are commonly used for 
this purpose. 

3 Where a user interface has to display an Indian language, the 
audio description may also be in the same language. 


11.1.3 Adaptable 
11.1.3.1 [nfo and relationships 


11.1.3.1.1 Info and relationships (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy 
the WCAG 2.1 Success Criterion 1.3.1 Info and 
Relationships. 
NOTE — In software, programmatic determinability is best 
achieved through the use of accessibility services provided by 
platform software to enable interoperability between software 
and assistive technologies and accessibility features of software 
(see also 11.5 interoperability with assistive technology). 


11.1.3.1.2 Info and relationships (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies for 
screen reading and where information is displayed on 
the screen, the ICT should provide auditory information 
that allows the user to correlate the audio with the 
information displayed on the screen. 


NOTES 


1 Many people who are legally blind still have visual ability, 
and use aspects of the visual display even if it cannot be fully 
comprehended. An audio alternative that is both complete 
and complementary includes all visual information such as 
focus or highlighting, so that the audio can be correlated with 
information that is visible on the screen at any point in time. 

2 Examples of auditory information that allows the user to 
correlate the audio with the information displayed on the 
screen include structure and relationships conveyed through 
presentation. 


IS 17802 (Part 1) : 2021 


11.1.3.2 Meaningful sequence 


11.1.3.2.1 Meaningful sequence (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy the 
WCAG 2.1 Success Criterion 1.3.2 Meaningful 
Sequence. 


11.1.3.2.2 Meaningful sequence (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies for 
screen reading and where information is displayed on 
the screen, the ICT should provide auditory information 
that allows the user to correlate the audio with the 
information displayed on the screen. 


NOTES 


1 Many people who are legally blind still have visual ability, 
and use aspects of the visual display even if it cannot be fully 
comprehended. An audio alternative that is both complete 
and complementary includes all visual information such as 
focus or highlighting, so that the audio can be correlated with 
information that is visible on the screen at any point in time. 


2 Examples of auditory information that allows the user to 
correlate the audio with the information displayed on the 
screen include structure and relationships conveyed through 
presentation. 


11.1.3.2.3 Sensory characteristics 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 1.3.3 Sensory Characteristics. 


11.1.3.2.4 Orientation 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 1.3.4 Orientation. 


11.1.3.2.5 Identify input purpose 
11.1.3.2.5.1 Identify input purpose (open functionality) 


Where ICT is non-web software that provides a user 
interface and supports access to assistive technologies 
for screen reading, it shall satisfy the WCAG 2.1 
Success Criterion 1.3.5 Identify Input Purpose. 


11.1.3.2.5.2 Identify input purpose (closed functionality) 


Where ICT is non-web software that provides a user 
interface and is closed to assistive technologies, in at 
least one mode of operation the ICT shall present to the 
user, in an audio form, the purpose of each input field 
collecting information about the user when the input 
field serves a purpose identified in the WCAG 2.1 Input 
Purposes for User Interface Components section. 
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11.1.4 Distinguishable 
11.1.4.1 Use of colour 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 1.4.1 Use of Colour. 


11.1.4.2 Audio control 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for audio control: 


If any audio in a software plays automatically for more 
than 3 s, either a mechanism is available to pause or 
stop the audio, or a mechanism is available to control 
audio volume independently from the overall system 
volume level. 


NOTES 


1 Since any part of a software that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
software, all content in the software (whether or not it is used 
to meet other success criteria) shall meet this success criterion. 
2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 1.4.2 Audio Control replacing “on a Web page” with 
“in a software”, “any content” with “any part of a software”, 
“whole page” with “whole software”, “on the Web page” with 
“in the software”, removing “See Conformance Requirement 
5: Non-Interference” and adding note 1. 


11.1.4.3 Contrast (minimum) 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 1.4.3 Contrast (Minimum). 


11.1.4.4 Resize text 


11.1.4.4.1 Resize text (open functionality) 


Where ICT is non-web software that provides a user 
interface and that supports access to enlargement 
features of platform or assistive technology, it shall 
satisfy the WCAG 2.1 Success Criterion 1.4.4 Resize 
Text. 


NOTES 


1 Content for which there are software players, viewers or 
editors with a 200 percent zoom feature would automatically 
meet this success criterion when used with such players, unless 
the content will not work with zoom. 

2 This success criterion is about the ability to allow users to 
enlarge the text on screen at least up to 200 percent without 
needing to use assistive technologies. This means that the 
application provides some means for enlarging the text 
200 percent (zoom or otherwise) without loss of content or 
functionality or that the application works with the platform 
features that meet this requirement. 


11.1.4.4.2 Resize text (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is not able to access the enlargement 
features of platform or assistive technology, it shall 
meet reguirement mentioned in 5.1.4 (Functionality 
closed to text enlargement). 
NOTE — Because the text rendering support in a closed 
environment may be more limited than the support found in 
user agents for the Web, meeting the present clause in a closed 
environment may place a much heavier burden on the content 
author. 


11.1.4.5 Images of text 


11.1.4.5.1 Images of text (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy the 
WCAG 2.1 Success Criterion 1.4.5 Images of Text. 


11.1.4.5.2 Images of text (closed functionality) 


Where ICT is non-web software that provides a user 
interface which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.6 
(speech output for non-text content). 


11.1.4.6 Void 
11.1.4.7 Void 
11.1.4.8 Void 
11.1.4.9 Void 
11.1.4.10 Reflow 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for reflow: 


Content can be presented without loss of information 
or functionality, and without requiring scrolling in two 
dimensions for: 


a) Vertical scrolling content at a width equivalent to 
320 CSS pixels; and 


b) Horizontal scrolling content at a height equivalent 
to 256 CSS pixels. 


Except for parts of the content which require two- 
dimensional layout for usage or meaning. 


NOTES 

1 320 CSS pixels is equivalent to a starting viewport 
width of 1280 CSS pixels wide at 400 percent zoom. For 
non-web software which are designed to scroll horizontally (for 
example, with vertical text), the 256 CSS pixels is equivalent 
to a starting viewport height of 1 024 px at 400 percent zoom. 
2 Examples of content which require two-dimensional layout 
are images, maps, diagrams, video, games, presentations, data 
tables, and interfaces where it is necessary to keep toolbars in 
view while manipulating content. 
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3 This success criterion is identical to the WCAG 2.1 success 
criterion 1.4.10 reflow replacing the original WCAG 2.1 notes 
with notes 1 and 2, above. 


11.1.4.11 Non-text contrast 


Where ICT is non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
1.4.11 Non- text Contrast. 


11.1.4.12 Text spacing 


Where ICT is non-web software that provides a user 
interface and that does not have a fixed size content 
layout area that is essential to the information being 
conveyed, it shall satisfy WCAG 2.1 Success Criterion 
1.4.12 Text spacing. 

NOTE — In respect of Indian languages, fonts and typography 


that provide adequate spacing between adjacent characters 
may be used as default or given as a choice. 


11.1.4.13 Content on hover or focus 


Where ICT is a non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
1.4.13 Content on hover or focus. 


11.2 Operable 

11.2.1 Keyboard Accessible 

11.2.1.1 Keyboard 

11.2.1.1.1 Keyboard (open functionality) 


Where ICT is non-web software that provides a user 
interface and that supports access to keyboards or 
a keyboard interface, it shall satisfy the WCAG 2.1 
Success Criterion 2.1.1 Keyboard. 
NOTE — This does not imply that software is required to 
directly support a keyboard or “keyboard interface”. Nor does 
it imply that software is required to provide a soft keyboard. 
Underlying platform software may provide device independent 
input services to applications that enable operation via a 
keyboard. Software that supports operation via such platform 
device independent services would be operable by a keyboard 
and would comply. 


11.2.1.1.2 Keyboard (closed functionality) 


Where ICT is non-web software that provides a user 
interface which is closed to keyboards or keyboard 
interface, it shall meet requirement mentioned in 
5.1.6.1 (operation without keyboard interface: Closed 
functionality). 


11.2.1.1.3 No keyboard trap 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for No keyboard trap: 


If keyboard focus can be moved to a component of 
the software using a keyboard interface, then focus 
can be moved away from that component using only 
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a keyboard interface, and, if it requires more than 
unmodified arrow or tab keys or other standard exit 
methods, the user is advised of the method for moving 
focus away. 


NOTES 


1 Since any part of a software that does not meet this success 
criterion can interfere with a user’s ability to use the whole 
software, it is necessary for all content in the software (whether 
or not it is used to meet other success criteria) to meet this 
success criterion. 

2 Standard exit methods may vary by platform. For example, 
on many desktop platforms, the Escape key is a standard 
method for exiting. 

3 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.1.2 No Keyboard Trap replacing “content”, “page” 
and “Web page” with “software”, removing “See Conformance 
Requirement 5: Non-Interference” and with the addition of 
Note 2 above and with Note 1 above re-drafted to avoid the use 
of the word “shall”. 


11.2.1.1.4 Void 
11.2.1.1.5 Character key shortcuts 


11.2.1.1.5.1 
functionality) 


Character key o shortcuts 


(open 
Where ICT is non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
2.1.4 Character Key Shortcuts. 


11.2.1.1.5.2 
functionality) 


Character key shortcuts (closed 


Where ICT is non-web software that provides a user 
interface, which is closed to keyboards or keyboard 
interface, it shall meet requirement 5.1.6.1 (operation 
without keyboard interface: Closed functionality). 


11.2.2 Enough Time 
11.2.2.1 Timing adjustable 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for Timing adjustable: 


For each time limit that is set by the software, at least 
one of the following is true: 


a) Turn off — The user is allowed to turn off the time 
limit before encountering it; 


b) Adjust — The user is allowed to adjust the time 
limit before encountering it over a wide range 
that is at least ten times the length of the default 
setting; 

c) Extend — The user is warned before time expires 
and given at least 20 s to extend the time limit with 
a simple action (for example, “press the space 
bar”), and the user is allowed to extend the time 
limit at least ten times; 
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d) Real-time Exception — The time limit is a required 
part of a real-time event (for example, an auction), 
and no alternative to the time limit is possible; 


e) Essential Exception — The time limit is essential 
and extending it would invalidate the activity; or 


f) 20 H Exception — The time limit is longer than 
20 h. 
NOTES 


1 This success criterion helps ensure that users can complete 
tasks without unexpected changes in content or context that 
are a result of a time limit. This success criterion should be 
considered in conjunction with WCAG 2.1 Success Criterion 
3.2.1, which puts limits on changes of content or context as a 
result of user action. 


2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.2.1 Timing Adjustable replacing “the content” with 
“software” and with the words “WCAG 2.1” added before the 
word “Success Criterion” in note 1 above. 


11.2.2.2 Pause, stop, hide 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for Pause, stop, hide: 


For moving, blinking, scrolling, or auto-updating 
information, all of the following are true: 


a) Moving, blinking, scrolling — For any moving, 
blinking or scrolling information that: 


1) starts automatically, 
2) lasts more than five seconds, and 


3) is presented in parallel with other content, 
there is a mechanism for the user to pause, 
stop, or hide it unless the movement, blinking, 
or scrolling is part of an activity where it is 
essential. 


b) Auto-updating — For 


information that: 


any auto-updating 


1) starts automatically; and 


2) is presented in parallel with other content, 
there is a mechanism for the user to pause, 
stop, or hide it or to control the frequency of 
the update unless the auto-updating is part of 
an activity where it is essential. 

NOTES 
1 For requirements related to flickering or flashing content, 
refer to WCAG 2.1 Guideline 2.3. 
2 This success criteria is applicable to all content in the 
software (whether or not there is an alternate accessible mode 
of operation of the software) since any part of a software that 
does not meet this success criterion can interfere with a user’s 
ability to use the whole software (including a user interface 
element that enables the user to activate the alternate accessible 
mode of operation). 


3 Content that is updated periodically by software or that 
is streamed to the user agent is not required to preserve or 


present information that is generated or received between the 
initiation of the pause and resuming presentation, as this may 
not be technically possible, and in many situations could be 
misleading to do so. 

4 An animation that occurs as part of a preload phase or similar 
situation can be considered essential if interaction cannot occur 
during that phase for all users and if not indicating progress 
could confuse users or cause them to think that content was 
frozen or broken. 

5 This is to be applied to all content. Any content, whether 
informative or decorative, that is updated automatically, blinks, 
or moves may create an accessibility barrier. 

6 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.2.2 Pause, Stop, Hide replacing “page” and 
“Web page” with “software”, removing “See Conformance 
Requirement 5: Non-Interference” in Note 2 of the success 
criterion, with the words “WCAG 2.1” added before the word 
“Guideline” in note 1 above, with Note 2 above re-drafted to 
avoid the use of the word “must” and with the addition of Note 
5 above. 


11.2.3 Seizures and Physical Reactions 


11.2.3.1 Three flashes or below threshold 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for three flashes or below 
threshold: 


Software does not contain anything that flashes more 
than three times in any one second period, or the flash is 
below the general flash and red flash thresholds. 


NOTES 


1 This success criteria is applicable to all content in the 
software (whether or not there is an alternate accessible mode 
of operation of the software) since any part of a software that 
does not meet this success criterion can interfere with a user’s 
ability to use the whole software (including a user interface 
element that enables the user to activate the alternate accessible 
mode of operation). 

2 This success criterion is identical to the WCAG 2.1 
success criterion 2.3.1 Three Flashes or Below Threshold 
replacing “Web pages” with “software”, “the whole page” 
with “the whole software”, “the Web page” with “the 
software” and removing “See Conformance Requirement 5: 
Non-Interference” and with note 1 above re-drafted to avoid 
the use of the word “must”. 


11.2.4 Navigable 


11.2.4.1 Void 


NOTES 

1 The related web page requirement “Bypass blocks” does not 
apply to single software programs, but to a specific definition 
of “sets of software programs” that are extremely rare. 
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2 Although not a requirement, it is generally considered best 
practice, and to address user needs, to be able to bypass blocks 
of content that are repeated within software. 


11.2.4.2 Void 


NOTES 

1 The related web page requirement “Page titled” does not 
apply to single software programs, but to a specific definition 
of “sets of software programs” that are extremely rare. 

2 Although the name of a software product could be a sufficient 
title if it describes the topic or purpose, software names are 
trademarked and trademark names cannot by law be descriptive 
names. It is not practical to make software names both unique 
and descriptive. 


11.2.4.3 Focus order 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for Focus order: 


If software can be navigated sequentially and the 
navigation sequences affect meaning or operation, 
focusable components receive focus in an order that 
preserves meaning and operability. 

NOTE — This success criterion is identical to the WCAG 2.1 


Success Criterion 2.4.3 Focus order replacing “Web page” 
with “software”. 


11.2.4.4 Link purpose (in context) 


Where ICT is non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
2.4.4 Link Purpose (In Context). 


11.2.4.5 Void 


NOTE — The related web page requirement for “multiple 
ways” applies to “Sets” of web pages. In software, the 
equivalent to “sets of web pages” would be “sets of software”, 
but these are extremely rare and an equivalent is not included 
in this clause on software requirements. 


11.2.4.6 Headings and labels 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 2.4.6 Headings and Labels. 


NOTE — In software, headings and labels are used to describe 
sections of content and controls respectively. In some cases, 
it may be unclear whether a piece of static text is a heading 
or a label. But whether treated as a label or a heading, the 
requirement is the same: that if they are present, they describe 
the topic or purpose of the item(s) they are associated with. 


11.2.4.7 Focus visible 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 2.4.7 Focus Visible. 
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11.2.5 Input Modalities 


11.2.5.1 Pointer gestures 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for pointer gestures: 


All functionality that uses multipoint or path-based 
gestures for operation can be operated with a single 
pointer without a path-based gesture, unless a multipoint 
or path-based gesture is essential. 


NOTES 


1 This requirement applies to non-web software that interprets 
pointer actions (that is, this does not apply to actions that are 
required to operate the user agent or assistive technology). 


2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.5.1 Pointer Gestures replacing the original WCAG 
2.1 note with Note 1 above. 


11.2.5.2 Pointer cancellation 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for Pointer cancellation: 


For functionality that can be operated using a single 
pointer, at least one of the following is true: 


a) No Down-Event — The down-event of the pointer 
is not used to execute any part of the function. 


b) Abort or Undo — Completion of the function is 
on the up-event, and a mechanism is available to 
abort the function before completion or to undo 
the function after completion. 


c) Up Reversal — The up-event reverses any 
outcome of the preceding down-event. 

d) Essential — Completing the function on the 
down-event is essential. 
NOTES 


1 Functions that emulate a keyboard or numeric keypad key 
press are considered essential. 


2 This requirement applies to non-web software that interprets 
pointer actions (that is, this does not apply to actions that are 
required to operate the user agent or assistive technology). 


3 This success criterion is identical to the WCAG 2.1 Success 
Criterion 2.5.2 Pointer Cancellation replacing the original 
WCAG 2.1 note with notes 1 and 2 above. 


11.2.5.3 Label in name 


11.2.5.3.1 Label in name (open functionality) 


Where ICT is non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
2.5.3 Label in Name. 
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11.2.5.3.2 Label in name (closed functionality) 


Where ICT is non-web software that provides a user 
interface which is closed to assistive technologies for 
screen reading, it should meet requirement 5.1.3.3 
(Auditory output correlation). 


11.2.5.4 Motion actuation 


Where ICT is non-web software that provides a user 
interface, it shall satisfy WCAG 2.1 Success Criterion 
2.5.4 Motion Actuation. 


11.3 Understandable 
11.3.1 Readable 
11.3.1.1 Language of software 


11.3.1.1.1 Language of software (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy the 
software success criterion as given below. 


Software success criterion for Language of software: 


The default human language of software can be 
programmatically determined. 


NOTES 

1 Where software platforms provide a “locale/language” 
setting, applications that use that setting and render their 
interface in that “locale/language” would comply with 
this success criterion. Applications that do not use the 
platform “locale/language” setting but instead use an 
accessibility-supported method for exposing the human 
language of the software would also comply with this success 
criterion. 

Applications implemented in technologies where assistive 
technologies cannot determine the human language and that do 
not support the platform “locale/language” setting may not be 
able to meet this success criterion in that locale/language. 

2 This success criterion is identical to the WCAG 2.1 Success 
Criterion 3.1.1 Language of page, replacing “each web page” 
with “software” and with the addition of note | above. 


11.3.1.1.2 Language of software (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.14 
(Spoken languages). 


11.3.1.2 Void 


NOTE — To apply the related web page requirement for 
“Language of parts” to software would require the marking-up 
of all text in all locations within the software. This would be 
impossible so an equivalent is not included in this clause on 
software requirements. 


11.3.2 Predictable 
11.3.2.1 On focus 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 3.2.1 On Focus. 


NOTE — Some compound documents and their user agents are 
designed to provide significantly different viewing and editing 
functionality depending upon what portion of the compound 
document is being interacted with (for example, a presentation 
that contains an embedded spreadsheet, where the menus and 
toolbars of the user agent change depending upon whether 
the user is interacting with the presentation content, or the 
embedded spreadsheet content). If the user uses a mechanism 
other than putting focus on that portion of the compound 
document with which they mean to interact (for example, by a 
menu choice or special keyboard gesture), any resulting change 
of context would not be subject to this success criterion because 
it was not caused by a change of focus. 


11.3.2.2 On input 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 3.2.2 On Input. 


11.3.2.3 Void 


NOTE — The related web page requirement for “consistent 
navigation” applies to “Sets” of web pages. While consistency 
within software is desirable, “sets of software” in the same sense 
as “sets of web pages”, are extremely rare and an equivalent is 
not included in this clause on software requirements. 


11.3.2.4 Void 


NOTE — The related web page requirement for “consistent 
identification” applies to “sets” of web pages. In software, the 
equivalent to “sets of web pages” would be “sets of software”, 
but these are extremely rare and an equivalent is not included 
in this clause on software requirements. 


11.3.3 Input Assistance 
11.3.3.1 Error identification 


11.3.3.1.1 Error identification (open functionality) 


Where ICT is non-web software that provides a 
user interface and that supports access to assistive 
technologies for screen reading, it shall satisfy the 
WCAG 2.1 Success Criterion 3.3.1 Error Identification. 


11.3.3.1.2 Error identification (closed functionality) 


Where ICT is non-web software that provides a user 
interface, which is closed to assistive technologies 
for screen reading, it shall meet requirement 5.1.3.15 
(non-visual error identification). 


11.3.3.2 Labels or instructions 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 3.3.2 Labels or Instructions. 
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11.3.3.3 Error suggestion 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the WCAG 2.1 Success 
Criterion 3.3.3 Error Suggestion. 


11.3.3.4 Error prevention (legal, financial, data) 


Where ICT is non-web software that provides a user 
interface, it shall satisfy the Software success criterion 
as given below. 


Software success criterion for Error prevention 
(legal, financial, data): 


For software that cause legal commitments or financial 
transactions for the user to occur, that modify or delete 
user- controllable data in data storage systems, or that 
submit user test responses, at least one of the following 
is true: 


a) Reversible — Submissions are reversible. 


b) Checked — Data entered by the user is checked 
for input errors and the user is provided an 
opportunity to correct them. 


Confirmed — A mechanism is available for 
reviewing, confirming, and correcting information 
before finalizing the submission. 

NOTE — This success criterion is identical to the WCAG 2.1 


Success Criterion 3.3.4 Error Prevention (Legal, Financial, 
Data) replacing “web pages” with “software”. 


11.4 Robust 
11.4.1 Compatible 
11.4.1.1 Parsing 


11.4.1.1.1 Parsing (open functionality) 


Where ICT is non-web software that provides a user 
interface and that supports access to any assistive 
technologies, it shall satisfy the success criterion as 
given below. 


Software success criterion for Parsing: 


For software that uses markup languages, in such a way 
that the markup is separately exposed and available 
to assistive technologies and accessibility features of 
software or to a user-selectable user agent, elements 
have complete start and end tags, elements are nested 
according to their specifications, elements do not 
contain duplicate attributes, and any IDs are unique, 
except where the specifications allow these features. 


NOTES 


1 Start and end tags that are missing a critical character in their 
formation, such as a closing angle bracket or a mismatched 
attribute value quotation mark are not complete. 

2 Markup is not always available to assistive technology or to 
user selectable user agents, such as browsers. In such cases, 
conformance to this [requirement] would have no impact on 
accessibility as it can for web content where it is exposed. 
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3 Examples of markup that is separately exposed and available 
to assistive technologies and to user agents include but are not 
limited to: documents encoded in HTML, ODF, and OOXML. 
In these examples, the markup can be parsed entirely in two 
ways: 
(a) by assistive technologies which may directly open the 
document, and 
(b) by assistive technologies using DOM APIs of user agents 
for these document formats. 


4 Examples of markup used internally for persistence of the 
software user interface that are never exposed to assistive 
technology include but are not limited to: XUL, and FXML. 
In these examples assistive technology only interacts with the 
user interface of generated software. 

5 This success criterion is identical to the WCAG 2.1 Success 
Criterion 4.1.1 Parsing replacing “In content implemented 
using markup languages” with “For software that uses markup 
languages, in such a way that the markup is separately exposed 
and available to assistive technologies and accessibility 
features of software or to a user-selectable user agent” with the 
addition of notes 2, 3 and 4 above. 


11.4.1.1.2 Parsing (closed functionality) 
Not applicable. 


NOTE — Where ICT is non-web software that provides a user 
interface, which is closed to all assistive technology it does 
not have to meet the “Parsing” success criterion mentioned 
under 11.4.1.1.1 because the intent of this success criterion is 
to provide consistency so that different user agents or assistive 
technologies will yield the same result. 


11.4.1.2 Name, role, value 


11.4.1.2.1 Name, role, value (open functionality) 


Where ICT is non-web software that provides a user 
interface and that supports access to any assistive 
technologies, it shall satisfy the Software success 
criterion as given below. 


Software success criterion for Name, role, value: 


For all user interface components (including but not 
limited to: form elements, links and components 
generated by scripts), the name and role can be 
programmatically determined; states, properties, 
and values that can be set by the user can be 
programmatically set; and notification of changes 
to these items is available to user agents, including 
assistive technologies. 


NOTES 


1 This success criterion is primarily for software 
developers who develop or use custom user interface 
components. Standard user interface components on most 
accessibility-supported platforms already meet this success 
criterion when used according to specification. 


2 For conforming to this success criterion, it is usually best 
practice for software user interfaces to use the accessibility 
services provided by platform software. These accessibility 
services enable interoperability between software user 
interfaces and both assistive technologies and accessibility 
features of software in standardized ways. Most platform 
accessibility services go beyond programmatic exposure of 
name and role, and programmatic setting of states, properties 
and values (and notification of same), and specify additional 
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information that could or should be exposed and/or set (for 
instance, a list of the available actions for a given user interface 
component, and a means to programmatically execute one of 
the listed actions). 


3 This success criterion is identical to the WCAG 2.1 success 
criterion 4.1.2 Name, Role, Value replacing the original 
WCAG 2.1 note with: “This success criterion is primarily for 
software developers who develop or use custom user interface 
components. Standard user interface components on most 
accessibility-supported platforms already meet this success 
criterion when used according to specification.” and the 
addition of note 2 above. 


11.4.1.2.2 Name, role, value (closed functionality) 
Not applicable. 


NOTE — Where ICT is non-web software that provides a user 
interface, which is closed to all assistive technology it does not 
have to meet the “Name, role, value” Software success criterion 
mentioned under 11.4.1.2.1 because this success criterion 
requires information in a programmatically determinable form. 


11.4.1.3 Status messages 


11.4.1.3.1 Status messages (open functionality) 


Where ICT is non-web software, it shall satisfy WCAG 
2.1 Success Criterion 4.1.3 Status Messages. 


11.4.1.3.2 Status messages (closed functionality) 
Not applicable. 


11.5 Interoperability with assistive technology 
11.5.1 Closed Functionality 


Where the closed functionality of software conforms 
to 5.1 (closed functionality) it shall not be required to 
conform with 11.5.2 to 11.5.2.17. 


11.5.2 Accessibility Services 


11.5.2.1 Platform accessibility service support for 
software that provides a user interface 


Platform software shall provide a set of documented 
platform services that enable software that provides 
a user interface running on the platform software to 
interoperate with assistive technology. 


Where a user interface concept corresponding to one 
of the 11.5.2.5 to 11.5.2.17 is supported within the 
software environment, the platform software should 
support that requirement. For example, selection 
attributes from 11.5.2.14 (Modification of focus and 
selection attributes) may not exist in environments 
that do not allow selection, which is most commonly 
associated with copy and paste. 


NOTES 

1 These define the minimum functionality of software 
providing user interfaces when using platform services. 

2 In some platforms these services may be called accessibility 
services, but in some other platforms these services may be 
provided as part of the user interface services. 

3 User interface services that provide accessibility support by 
default are considered to be part of the services provided to 


conform to this clause (for example, the service for creating 
a new user interface element provides role, state, boundary, 
name and description). 


4 To comply with this requirement the platform software can 
provide its own set of services or expose the services provided 
by its underlying platform layers, if those services conform to 
this requirement. 


5 Within specific programming environments, the technical 
attributes associated with the user interface properties 
described in 11.5.2.5 to 11.5.2.17 might have different names 
than those used within the clauses. 


6 Provision to choose language setting may be supported 
by the platform software. It shall include choice of all 
Indian languages figuring in the 8th schedules of the Indian 
constitution. 


11.5.2.2 Platform accessibility service support for 
assistive technologies 


Platform software shall provide a set of documented 
platform accessibility services that enable assistive 
technology to interoperate with software that provides 
a user interface running on the platform software. 


Where a user interface concept corresponding to one 
of the 11.5.2.5 to 11.5.2.17 is supported within the 
software environment, the platform software should 
support that requirement. For example, selection 
attributes from 11.5.2.14 (Modification of focus and 
selection attributes) may not exist in environments 
that do not allow selection, which is most commonly 
associated with copy and paste. 


NOTES 
1 These define the minimum functionality available to assistive 
technologies when using platform services. 


2 The definition of platform in 3.1 applies to software that 
provides services to other software, including but not limited 
to, operating systems, web browsers, virtual machines. 


3 In some platforms these services may be called accessibility 
services, but in some other platforms these services may be 
provided as part of the user interface services. 

4 Typically, these services belong to the same set of services 
that are described in 11.5.2.1. 


5 To comply with this requirement the platform software can 
provide its own set of services or expose the services provided 
by its underlying platform layers, if those services conform to 
this requirement. 


6 The platform software shall provide for programmatically 
determining user interface language so that these are exposed 
to assistive technologies. 


11.5.2.3 Use of accessibility services 


Where the software provides a user interface, it shall 
use the applicable documented platform accessibility 
services. If the documented platform accessibility 
services do not allow the software to meet the applicable 
requirements of 11.5.2.5 to 11.5.2.17, then software that 
provides a user interface shall use other documented 
services to interoperate with assistive technology. 
NOTE — The term “documented platform accessibility 


services” refers to the set of services provided by the platform 
according to 11.5.2.1 and 11.5.2.2. 
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It is best practice to develop software using toolkits 
that automatically implement the underlying platform 
accessibility services. 


11.5.2.4 Assistive technology 


Where the ICT is assistive technology, it shall use the 
documented platform accessibility services. 


NOTES 


1 The term “documented platform accessibility services” refers 
to the set of services provided by the platform according to 
11.5.2.1 and 11.5.2.2. 


2 Assistive technology can also use other documented 
accessibility services. 


11.5.2.5 Object information 


Where the software provides a user interface it shall, 
by using the services as described in 11.5.2.3, make the 
user interface elements’ role, state(s), boundary, name, 
and description programmatically determinable by 
assistive technologies. 


11.5.2.6 Row, column, and headers 


Where the software provides a user interface it shall, by 
using the services as described in 11.5.2.3, make the row 
and column of each cell ina data table, including headers 
of the row and column if present, programmatically 
determinable by assistive technologies. 


11.5.2.7 Values 


Where the software provides a user interface, it shall, 
by using the services as described in 11.5.2.3, make 
the current value of a user interface element and any 
minimum or maximum values of the range, if the user 
interface element conveys information about a range 
of values, programmatically determinable by assistive 
technologies. 


11.5.2.8 Label relationships 


Where the software provides a user interface, it shall 
expose the relationship that a user interface element 
has as a label for another element, or of being labelled 
by another element, using the services as described in 
11.5.2.3, so that this information is programmatically 
determinable by assistive technologies. 


11.5.2.9 Parent-child relationships 


Where the software provides a user interface it shall, 
by using the services as described in 11.5.2.3, make 
the relationship between a user interface element and 
any parent or children elements programmatically 
determinable by assistive technologies. 


11.5.2.10 Text 


Where the software provides a user interface it shall, 
by using the services as described in 11.5.2.3, make the 
text contents, text attributes, and the boundary of text 
rendered to the screen programmatically determinable 
by assistive technologies. 
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11.5.2.11 List of available actions 


Where the software provides a user interface it shall, 
by using the services as described in 11.5.2.3, make a 
list of available actions that can be executed on a user 
interface element, programmatically determinable by 
assistive technologies. 


11.5.2.12 Execution of available actions 


Where permitted by security requirements, software 
that provides a user interface shall, by using the services 
as described in 11.5.2.3, allow the programmatic 
execution of the actions exposed according to 11.5.2.11 
by assistive technologies. 


NOTES 


1 In some cases, the security requirements imposed on a 
software product may forbid external software from interfering 
with the ICT product. Examples of systems under strict security 
requirements are systems dealing with intelligence activities, 
cryptologic activities related to national security, command 
and control of military forces. 


2 Assistive technologies may be required to maintain the same 
level of security as the standard input mechanisms supported 
by the platform. 


11.5.2.13 Tracking of focus and selection attributes 


Where software provides a user interface it shall, by 
using the services as described in 11.5.2.3, make 
information and mechanisms necessary to track focus, 
text insertion point, and selection attributes of user 
interface elements programmatically determinable by 
assistive technologies. 


11.5.2.14 Modification of focus and selection attributes 


Where permitted by security requirements, software 
that provides a user interface shall, by using the services 
as described in 11.5.2.3, allow assistive technologies to 
programmatically modify focus, text insertion point, 
and selection attributes of user interface elements 
where the user can modify these items. 


NOTES 


1 In some cases, the security requirements imposed on a 
software product may forbid external software from interfering 
with the ICT product and so this requirement would not apply. 
Examples of systems under strict security requirements are 
systems dealing with intelligence activities, cryptologic 
activities related to national security, command and control of 
military forces. 

2 Assistive technologies may be required to maintain the same 
level of security as the standard input mechanisms supported 
by the platform. 


11.5.2.15 Change notification 


Where software provides a user interface it shall, 
by using the services as described in 11.5.2.3, 
notify assistive technologies about changes in those 
programmatically determinable attributes of user 
interface elements that are referenced in requirements 
11.5.2.5 to 11.5.2.11 and 11.5.2.13. 
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11.5.2.16 Modifications of states and properties 


Where permitted by security requirements, software 
that provides a user interface shall, by using the services 
as described in 11.5.2.3, allow assistive technologies to 
programmatically modify states and properties of user 
interface elements, where the user can modify these 
items. 


NOTES 


1 In some cases, the security requirements imposed on a 
software product may forbid external software from interfering 
with the ICT product and so this requirement would not apply. 
Examples of systems under strict security requirements are 
systems dealing with intelligence activities, cryptologic 
activities related to national security, command and control of 
military forces. 


2 Assistive technologies may be required to maintain the same 
level of security as the standard input mechanisms supported 
by the platform. 


11.5.2.17 Modifications of values and text 


Where permitted by security requirements, software 
that provides a user interface shall, by using the services 
as described in 11.5.2.3, allow assistive technologies 
to modify values and text of user interface elements 
using the input methods of the platform, where a user 
can modify these items without the use of assistive 
technology. 


NOTES 


1 In some cases, the security requirements imposed on a 
software product may forbid external software from interfering 
with the ICT product and so this requirement would not apply. 
Examples of systems under strict security requirements are 
systems dealing with intelligence activities, cryptologic 
activities related to national security, command and control of 
military forces. 


2 Assistive technologies may be required to maintain the same 
level of security as the standard input mechanisms supported 
by the platform. 


11.6 Documented Accessibility Usage 


11.6.1 User Control of Accessibility Features 


Where software is a platform, it shall provide sufficient 
modes of operation for user control over those platform 
accessibility features documented as intended for users. 


11.6.2 No Disruption of Accessibility Features 


Where software provides a user interface, it shall not 
disrupt those documented accessibility features that 
are defined in platform documentation except when 
requested to do so by the user during the operation of 
the software. 


11.7 User preferences 


Where software is not designed to be isolated from 
its platform, and provides a user interface, that user 
interface shall follow the values of the user preferences 
for platform settings for: units of measurement, colour, 


contrast, font type, font size, and focus cursor except 
where they are overridden by the user. 


NOTES 


1 Software that is isolated from its underlying platform has no 
access to user settings in the platform and thus cannot adhere 
to them. 


2 For web content, the underlying platform is the user agent. 


3 This does not preclude the software from having additional 
values for a setting as long as there is one mode where the 
application will follow the system settings even if more 
restricted. 


4 User preference setting may include default language 
settings. In turn, these may be programmatically determined so 
that assistive technologies are aware of the settings to respond 
to user’s choice. 


11.8 Authoring Tools 
11.8.1 General (Informative) 


For those creating web content authoring tools, ATAG 
2.0 provides information that can be of interest to those 
who want to go beyond these requirements. 


NOTE — This is applicable both to standalone and to 
web-based authoring tools. 


11.8.2 Content Technology 


Authoring tools shall conform to 11.8.2 to 11.8.5 to 
the extent that information required for accessibility 
is supported by the format used for the output of the 
authoring tool. 


11.8.3 Accessible Content Creation 


Authoring tools shall enable and guide the production 

of content that conforms to 9 (Web content) or 10 

(non-Web content) as applicable. 
NOTE — Authoring tools may rely on additional tools where 
conformance with specific requirements is not achievable by a 
single tool. For example, a video editing tool may enable the 
creation of video files for distribution via broadcast television 
and the web, but authoring of caption files for multiple formats 
may be provided by a different tool. 


11.8.4 Preservation of Accessibility Information in 
Transformations 


If the authoring tool provides restructuring 
transformations or re-coding transformations, then 
accessibility information shall be preserved in the 
output if equivalent mechanisms exist in the content 
technology of the output. 


NOTES 


1 Restructuring transformations are transformations in which 
the content technology stays the same, but the structural 
features of the content are changed (or example, linearizing 
tables, splitting a document into pages). 


2 Re-coding transformations are transformations in which the 
technology used to encode the content is changed. 


11.8.5 Repair Assistance 


If the accessibility checking functionality of an 
authoring tool can detect that content does not meet a 
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requirement of 9 (Web) or 10 (non-web documents) as 
applicable, then the authoring tool shall provide repair 
suggestion(s). 

NOTE This preclude and 


semi-automated repair which is possible (and encouraged) for 
many types of content accessibility problems. 


11.8.6 Templates 


When an authoring tool provides templates, at least 
one template that supports the creation of content 
that conforms to the requirements of 9 (Web) or 10 
(non-web documents) as applicable shall be available 
and identified as such. 


does not automated 


NOTE — The template may include fields to indicate language 
setting of the user. 


12 DOCUMENTATION AND 
SERVICES 


SUPPORT 


12.1 Product Documentation 


12.1.1 Accessibility and Compatibility Features 


Product documentation provided with the ICT whether 
provided separately or integrated within the ICT 
shall list and explain how to use the accessibility and 
compatibility features of the ICT. 


NOTES 

1 Accessibility and compatibility features include accessibility 
features that are built-in and accessibility features that provide 
compatibility with assistive technology. 

2 It is best practice to use WebSchemas/Accessibility 2.0 to 
provide meta data on the accessibility of the ICT. 

3 The accessibility statement and help pages are both examples 
of the provision of product information. 


4 Where Indian language is supported, product documentation 
may also be offered in the language opted by the user. 


12.1.2 Accessible Documentation 


Product documentation provided with the ICT shall 
be made available in at least one of the following 
electronic formats: 


a) a Web format that conforms to the requirements of 
9; or 
b) 


anon-web format that conforms to the requirements 
of 10. 


NOTES 


1 This does not preclude the possibility of also providing the 
product documentation in other formats (electronic, printed or 
audio) that are not accessible. 

2 It also does not preclude the possibility of providing alternate 
formats that meet the needs of some specific type of users (for 
example, Braille documents for blind people or easy-to-read 
information for persons with limited cognitive, language and 
learning abilities). 

3 Where documentation is incorporated into the ICT, the 
documentation falls under the requirements for accessibility in 
this standard. 

4 Auser agent that supports automatic media conversion would 
be beneficial to enhancing accessibility. 
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5 Where product documentation is offered in an Indian 
language of choice to the end-user, alternate media shall also 
be in the same language. 


12.2 Support Services 
12.2.1 General (Informative) 


ICT support services include, but are not limited to: help 
desks, call centres, technical support, relay services and 
training services. 


NOTES 


1 In respect of an Indian language user, ICT support services 
shall also be provided in the same language of choice of the 
end-user to the maximum extent across all channels of support. 


2 Support service representatives shall be trained to meet the 
needs of persons with disabilities. 


Examples 


1 Trouble shooting for assistive technology users — such 
representatives shall be able to outline instructions to clients 
for troubleshooting a problem using screen readers. 


2 customer appropriate instructions — such as asking them to 
double tap the third button from the top, as opposed to saying 
a red-coloured icon, when the customer is blind/ visually- 
impaired. 


12.2.2 Information on Accessibility and Compatibility 
Features 


ICT support services shall provide information on 
the accessibility and compatibility features that are 
mentioned in the product documentation. 

NOTE — Accessibility and compatibility features include 


accessibility features that are built-in and accessibility features 
that provide compatibility with assistive technology. 


12.2.3 Effective Communication 


ICT support services shall accommodate the 
communication needs of individuals with disabilities 
either directly or through a referral point. 

NOTE — One of the forms of communication with individuals 


with disabilities could be choice of Indian language, in 
whatever form — text, images, video, voice or captioning. 


12.2.4 Accessible Documentation 


Documentation provided by support services shall 
be made available in at least one of the following 
electronic formats: 


a) a Web format that conforms to 9; or 


b) anon-web format that conforms to 10. 
NOTES 
1 This does not preclude the possibility of also providing the 
documentation in other formats (electronic or printed) that are 
not accessible. 
2 It also does not preclude the possibility of providing alternate 
formats that meet the needs of some specific type of users 
(for example, Braille documents for blind people or easy-to- 
read information for persons with limited cognitive, language 
and learning abilities). 
3 Where the support documentation is incorporated into 
the ICT, the documentation falls under the requirements for 
accessibility in this standard. 
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4 Auser agent that supports automatic media conversion would 
be beneficial to enhancing accessibility. ICT providing relay or 
emergency service access. 


13 ICT PROVIDING RELAY OR EMERGENCY 
SERVICE ACCESS 


13.1 Relay Services Requirements 


13.1.1 General (Informative) 


Relay services enable users of different modes of 
communication for example, text, sign, speech, 
to interact remotely through ICT with two-way 
communication by providing conversion between 
the modes of communication, normally by a human 
operator. 


It is best practice to meet the applicable relay service 
requirements of ETSI ES 202 975. 


NOTE — Relay services need to support users of a chosen 
Indian language across different modes of communication 
namely, text, sign, speech. 


13.1.2 Text Relay Services 


Where ICT is intended to provide a text relay service, 
the text relay service shall enable text users and speech 
users to interact by providing conversion between the 
two modes of communication. 


NOTE — Text relay services may support Indian language 
users maximally. 


13.1.3 Sign Relay Services 


Where ICT is intended to provide a sign relay service, 
the sign relay service shall enable sign language users 
and speech users to interact by providing conversion 
between the two modes of communication. 


NOTES 


1 Sign relay services are also sometimes referred to as sign 
language relay services or video relay services. 


2 Sign relay services shall follow Indian Sign Language (ISL). 


13.1.4 Lip-reading Relay Services 


Where ICT is intended to provide a lip-reading relay 
service, the lip-reading service shall enable lip-readers 
and voice telephone users to interact by providing 
conversion between the two modes of communication. 


13.1.5 Captioned Telephony Services 


Where ICT is intended to provide a captioned telephony 
service, the captioned telephony service shall assist a 
deaf or hard of hearing user in a spoken dialogue by 
providing text captions translating the incoming part of 
the conversation. 


NOTE — The captions shall be as per this standard and shall 
support Indian languages. 


13.1.6 Speech to Speech Relay Services 


Where ICT is intended to provide a speech-to-speech 
relay service, the speech-to-speech relay service shall 
enable telephone users who are speech impaired, have 


limited cognitive, language and learning abilities, as 
well as any other user, to communicate by providing 
assistance between them. 

NOTE — Speech to speech relay service may also enable 


users speaking different Indian languages to communicate 
using the assistance provided between them. 


13.2 Access to Relay Services 


Where ICT systems support two-way communication, 
and the system is specified for use with relay services, 
access to those relay services shall not be prevented for 
outgoing and incoming calls involving: voice, RTT, or 
video, either individually or in combinations supported 
by both the relay service and the ICT system. 


NOTES 


1 The purpose of this requirement is to achieve functionally 
equivalent communication access by persons with disabilities. 
2 The system may be specified as needing to work with relay 
services by, for example, procurers, regulators, or product 
specifications. 
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13.3 Access to Emergency Services 


Where ICT systems support two-way communication, 
and the system is specified for use with emergency 
services, access to those emergency services shall 
not be prevented for outgoing and incoming calls 
involving: voice, RTT, or video, either individually 
or in combinations supported by both the emergency 
service and the ICT system. 


NOTES 

1 The purpose of this requirement is to achieve functionally 
equivalent communication access to the emergency service by 
persons with disabilities. 

2 The system may be specified as needing to work with 
emergency services by, for example: procurers, regulators, or 
product specifications. 

3) Support to Indian language input and display and to Indian 
Sign Language must be ensured. 
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ANNEX A 
( Foreword ) 
( Informative ) 
RELATIONSHIP OF THIS STANDARD WITH OTHER DEPARTMENTS UNDER GOI 


This standard brings out the current Indian legal 
context of accessibility, —including those pertaining to 
ICT, especially as provided by Rights of Persons with 
Disabilities Act, 2016. 


There are also various other sectoral standards, 
guidelines, rules and compliance requirements that have 
been announced by various ministries, departments 
and government agencies, many in response to RPwD 
Act, 2016. Some have existed even prior to the coming 
into being of the above. Of consequence here are those 
relating to various components of ICT and the use of 
ICT in various sectors. 


Compliance to Guidelines for Indian Government Apps 
and Websites (GIGW 2.0), and hence WCAG 2.0 has 
been made mandatory by Department of Administrative 
Reforms and Public Grievances (DARPG) for all 
government websites and Department of Empowerment 
of Persons with Disabilities (DEPwD) has set goals, 
currently, based on that. The main difference this 
standard brings in that context, is the choice of WCAG 
2.1 AA compliance criteria in lieu of WCAG 2.0 AA 
expected in GIGW 2.0. Compliance to this standard 
is backward compatible with GIGW 2.0. Additional 
success criteria have been brought in here. In addition, 
the context of the applicability of this standard for 
wider-users, government, private and non-government 
as mandated by the RPwD Act, 2016 should be kept in 
mind. As also the wider scope of this standard in terms 
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of functionalities, cutting across all ICT products and 
services, practically. 


RBI had mandated certain guidelines for compliance of 
banking sector to accessibility and one can expect that 
sector also to upgrade their requirements. 


Department of Telecommunications (DoT), through 
a TRAI guideline, has mandated all mobile handset 
suppliers to support Indian language keyboards in 
shipping of mobile handsets (source: IS 16333-3, 
IS 16350 : 2016). 


Mol&B has announced targets for use of Indian Sign 
Language and Captioning and Subtitling in respect 
of all broadcast service providers [source Mol & B 
Accessibility Standard]. 


Ministry of Education has also taken steps in respect of 
Education sector. One can expect that sector to be an 
important and early adopter. 


This standard is intended to rally support of all 
stakeholders and trigger widespread availability and 
adoption of ICT products and services compliant to this 
standard. 


Indian IT sector, Telecom sector, Start-up sector, 
R&D labs, Academia and NGOs will play a key role 
in bringing out affordable, innovative and compliant 
ICT products and services to the market and large-scale 
adoption to the benefit of PwD users and other sections 
who will also benefit. 
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ANNEX B 
( Informative ) 
( Clause 4.1 ) 


RELATIONSHIP BETWEEN REQUIREMENTS AND 
FUNCTIONAL PERFORMANCE STATEMENTS 


B-1 RELATIONSHIPS BETWEEN CLAUSES 
5 TO 13 AND THE FUNCTIONAL 
PERFORMANCE STATEMENTS 


Table 4 shows which of the requirements set out 
in clauses 5 to 13 support each of the functional 
performance statements set out in clause 4.2. 


To allow Table 4 to fit the page, the abbreviations 
shown in Table 3 have been used in the column headers 
of Table 4. 


The following abbreviations have been used to represent 
the relationship between the requirements in clauses 
5 to 13 and the functional performance statements: 


a) P Primary relationship. The requirement 
supports the functional performance statement. 


b) S = Secondary relationship. The requirement 
provides partial support for the functional 
performance statement because some users may 
use the feature in specific situations. 


Table 3 Key to the Column Header Designations Used in Table 4 
( Clause B-1 ) 


Clause Number Column Header 


Functional Performance Statement 


Abbreviation 
4.2.1 WV Usage without vision 
4.2.2 LV Usage with limited vision 
4.2.3 WPC Usage without perception of colour 
4.2.4 WH Usage without hearing 
4.2.5 LH Usage with limited hearing 
4.2.6 WVC Usage without vocal capability 
4.2.7 LMS Usage with limited manipulation or strength 
4.2.8 LR Usage with limited reach 
4.2.9 PST Minimize photosensitive seizure triggers 
4.2.10 LC Usage with limited cognition 
4.2.11 PR Privacy 
4.2.12 IL Indian language support 
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VS 


Table 4 Reguirements in Clauses 5 to 13 Supporting the Accessibility 


Needs Expressed in the Functional Performance Statements 


( Clause B-1 ) 


Requirements 


4.2.1 
WV 


4.2.2 
LV 


4.2.3 
WPC 


4.2.4 
WH 


4.2.5 
LH 


4.2.6 
WVC 


4.2.7 
LMS 


4.2.8 
LR 


4.2.9 
PST 


4.2.10 
LC 


4.2.11 


5.1.2.1 Closed functionality 


5.1.2.2 Assistive technology 


5.1.3.1 General (belongs to 5.1.3 Non-visual access) 


TT 


5.1.3.2 Auditory output delivery including speech 


T 


5.1.3.3 Auditory output correlation 


5.1.3.4 Speech output user control 


5.1.3.5 Speech output automatic interruption 


5.1.3.6 Speech output for non-text content 


5.1.3.7 Speech output for video information 


5.1.3.8 Masked entry 


NININ 


5.1.3.9 Private access to personal data 


5.1.3.10 Non-interfering audio output 


Ulu 


5.1.3.11 Private listening volume 


5.1.3.12 Speaker volume 


5.1.3.13 Volume reset 


5.1.3.14 Spoken languages 


5.1.3.15 Non-visual error identification 


alulalalulalalulaulalalalululun 


5.1.3.16 Receipts, tickets, and transactional outputs 


5.1.4 Functionality closed to text enlargement 


uUlmU| ul) ul Ul ul ululululül ulu 


maolalalalalalualalalaluluaulalal|ulualan 


5.1.5 Visual output for auditory information 


5.1.6.1 Operation without keyboard interface (closed functionality) 


5.1.6.2 Operation without keyboard interface (Input focus) 


5.1.7 Access without speech 


ulualw 


5.2 Activation of accessibility features 


5.3 Biometrics 
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Table 4 ( Continued) 


Requirements 


4.2.1 


4.2.2 


4.2.4 


4.2.5 


4.2.6 


4.2.8 
LR 


4.2.9 4.2.10 
PST LC 


4.2.11 


4.2.12 


5.4 Preservation of accessibility information during conversion 


S 


5.5.1 Means of operation 


5.5.2 Operable part discernibility 


5.6.1 Tactile or auditory status (belongs to 5.6 locking or toggle controls) 


5.6.2 Visual status 


5.7 Key repeat 


5.8 Double-strike key acceptance 


5.9 Simultaneous user actions 


w/t) tO] 


5.10 Support to Indian languages 


5.11 Indian sign language 


| 
NINININININ 


5.12 Captioning and sub-titling 


ac) 


6.1 Audio bandwidth for speech (informative recommendation) 


6.2.1.1 RTT communication 


6.2.1.2 Concurrent voice and text 


6.2.2.1 Visually distinguishable display 


6.2.2.2 Programmatically determinable send and receive direction 


6.2.2.3 Speaker identification 


Ulu 


6.2.2.4 Visual indicator of Audio with RTT 


6.2.3 Interoperability 


6.2.4 Real-time text responsiveness 


oo eo aoe eo le ee a 


NILNAINININIWN]! S/n] Ol] vl) vs” 


NINININININININM 


6.3 Caller ID 


6.4 Alternatives to voice-based services 


6.5.2 (Video) Resolution 


6.5.3 (Video) Frame rate 


6.5.4 Synchronization between audio and video 


6.5.5 Visual indicator of audio with video 


I a ulu 


Ululrmal ulu 


alalalalu 
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Table 4 ( Continued) 


Requirements 


4.2.1 


4.2.2 


4.2.6 
WVC 


4.2.7 
LMS 


4.2.8 
LR 


4.2.9 
PST 


4.2.10 
LC 


4.2.11 
PR 


4.2.12 


6.5.6 Speaker identification with video (sign language) communication 


6.6 Alternatives to video-based services 


7.1.1 Captioning playback 


7.1.2 Captioning synchronization 


7.1.3 Preservation of captioning 


7.1.4 Captions characteristics 


7.1.5 Spoken subtitles 


7.2.1 Audio description playback 


ala 


7.2.2 Audio description synchronization 


7.2.3 Preservation of audio description 


7.3 User controls for captions and audio description 


8.1.2 Standard connections 


8.1.3 Colour 


Al Ulu] Vi) a wl] aN 


alalalalulalalalulula 


8.2.1.1 Speech volume range 


8.2.1.2 Incremental volume control 


8.2.2.1 Fixed-line devices (8.2.2 Magnetic coupling) 


8.2.2.2 Wireless communication devices 


Ul wj] 


8.3.0 Stationary ICT, General (informative recommendation) 


8.3.1 Forward or side reach 


8.3.2.1 Unobstructed high forward reach 


8.3.2.2 Unobstructed low forward reach 


8.3.2.3.1 Obstructed forward reach - Clear space 


8.3.2.3.2 Obstructed (< 510 mm) forward reach 


8.3.2.3.3 Obstructed (< 635 mm) forward reach 


8.3.2.4 Knee and Toe clearance width 


8.3.2.5 Toe Clearance 


ool a ee ul ululu( ulu 
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Table 4 ( Continued ) 


Requirements 


4.2.1 


4.2.2 


4.2.4 


4.2.5 


4.2.8 


— 
A 


4.2.9 
PST 


4.2.10 
LC 


4.2.11 
PR 


4.2.12 


8.3.2.6 Knee Clearance 


8.3.3.1 Unobstructed high side reach 


8.3.3.2 Unobstructed low side reach 


8.3.3.3.1 Obstructed (< 255 mm) side reach 


8.3.3.3.2 Obstructed (< 610 mm) side reach 


8.3.4.1 Change in level 


8.3.4.2 Clear floor or ground space 


8.3.4.3.1 Approach - General 


8.3.4.3.2 Forward approach 


8.3.4.3.3 Parallel approach 


8.3.5 Visibility 


8.3.6 Installation instructions 


gels aos ewe eos eo eo ee oe eo ee ae 


8.4.1 Numeric keys 


8.4.2.1 Means of operation of mechanical parts 


8.4.2.2 Force of operation of mechanical parts 


8.4.3 Keys, tickets and fare cards 


8.5 Tactile indication of speech mode 


9.1.1.1 Non-text content 


9.1.2.1 Audio-only and video-only (pre-recorded) 


wa) ul; S 


9.1.2.2 Captions (pre-recorded) 


Ulu 


uUlula 


9.1.2.3 Audio description or media alternative (pre-recorded) 


T 


9.1.2.4 Captions (live) 


9.1.2.5 Audio description (pre-recorded) 


9.1.3.1 Info and relationships 


9.1.3.2 Meaningful sequence 


9.1.3.3 Sensory characteristics 


Ulu) e 


WInI nin 


NININININININ!/ NIM 
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Table 4 ( Continued) 


Requirements 


4.2.1 


4.2.2 
LV 


4.2.4 


4.2.5 
LH 


4.2.6 
WVC 


4.2.8 
LR 


4.2.9 
PST 


4.2.10 
LC 


4.2.11 


4.2.12 


9.1.3.4 Orientation 


P 


S 


9.1.3.5 Identify input purpose 


9.1.4.1 Use of colour 
9.1.4.2 Audio control 


T 


9.1.4.3 Contrast (minimum) 


9.1.4.4 Resize text 


9.1.4.5 Images of text 


9.1.4.10 Reflow 


9.1.4.11 Non-text contrast 


9.1.4.12 Text spacing 


9.1.4.13 Content on hover or focus 


9.2.1.1 Keyboard 


9.2.1.2 No keyboard trap 


W ~~ =] 


9.2.1.4 Character key shortcuts 


9.2.2.1 Timing adjustable 


9.2.2.2 Pause, stop, hide 


oo ao aoe ulu 


H o | ua 


9.2.3.1 Three flashes or below threshold 


9.2.4.1 Bypass blocks 


9.2.4.2 Page titled 


9.2.4.3 Focus order 


9.2.4.4 Link purpose (in context) 


9.2.4.5 Multiple ways 


9.2.4.6 Headings and labels 


9.2.4.7 Focus visible 


T ST ee a oe o a 


ulululul aa 


ulalalwum 


9.2.5.1 Pointer gestures 


9.2.5.2 Pointer cancellation 


9.2.5.3 Label in name 


a-a ke-0 eos ee eo oe a oe) 


wv) ul! 


ea aoe ool eo ia- eo eo ee e-a Gae 
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Table 4 ( Continued) 


Requirements 


> 
ied 
an 


4.2.4 


4.2.5 


4.2.6 


4.2.11 


9.2.5.4 Motion actuation 


9.3.1.1 Language of page 
9.3.1.2 Language of parts 


9.3.2.1 On focus 


9.3.2.2 On Input 


9.3.2.3 Consistent navigation 


9.3.2.4 Consistent identification 


9.3.3.1 Error identification 


9.3.3.2 Labels or instructions 


9.3.3.3 Error suggestion 


9.3.3.4 Error prevention (legal, financial, data) 


Ulu) ul ul MW] VI) WIV ALnI IN 


9.4.1.1 Parsing 


9.4.1.2 Name, role, value 


9.4.1.3 Status messages 


9.6 WCAG Conformance requirements 


10.1.1.1 Non-text content 


ala 


10.1.2.1 Audio-only and video-only (pre-recorded) 


v| a a a a KI 


Ulu ml] wml wml NI] wo] ol] eo] ul ulululula 


10.1.2.2 Captions (pre-recorded) 


aM) e u ts] 


10.1.2.3 Audio description or media alternative (pre-recorded) 


10.1.2.4 Captions (live) 


10.1.2.5 Audio description (pre-recorded) 


10.1.3.1 Info and relationships 


10.1.3.2 Meaningful sequence 


10.1.3.3 Sensory characteristics 


10.1.3.4 Orientation 


10.1.3.5 Identify input purpose 


alaJlulalalalululalalülü 
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Table 4 ( Continued) 


Reguirements 


422 


4.2.4 


4.2.5 


4.2.6 
WVC 


4.2.7 
LMS 


4.2.8 
LR 


4.2.9 
PST 


4.2.10 
LC 


4.2.11 


4.2.12 


10.1.4.1 Use of colour 


10.1.4.2 Audio control 


10.1.4.3 Contrast (minimum) 


10.1.4.4 Resize text 


10.1.4.5 Images of text 


10.1.4.10 Reflow 


10.1.4.11 Non-text contrast 


10.1.4.12 Text spacing 


10.1.4.13 Content on hover or focus 


10.2.1.1 Keyboard 


10.2.1.2 No keyboard trap 


Tl Ul) UO) ul ululul ulu 


10.2.1.4 Character key shortcuts 
10.2.2.1 Timing adjustable 


"g 


nin] 


10.2.2.2 Pause, stop, hide 


uUlulul ult 


uUulula 


10.2.3.1 Three flashes or below threshold 


10.2.4.2 Document titled 


10.2.4.3 Focus order 


10.2.4.4 Link purpose (in context) 


10.2.4.6 Headings and labels 
10.2.4.7 Focus visible 


> ai ee | 


ulala 


10.2.5.1 Pointer gestures 


10.2.5.2 Pointer cancellation 


10.2.5.3 Label in name 


10.2.5.4 Motion actuation 


oo ao eee eo eo eo ee) 


a a 


10.3.1.1 Language of page 


10.3.1.2 Language of parts 


(ra mE e E e a a a- e a a ulu 
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Table 4 ( Continued) 


Requirements 


> 
ied 
an 


4.2.2 4.2.3 4.2.4 


4.2.5 


4.2.6 


4.2.11 


4.2.12 


10.3.2.1 On focus 


10.3.2.2 On input 


10.3.3.1 Error identification 


10.3.3.2 Labels or instructions 


10.3.3.3 Error suggestion 


10.3.3.4 Error prevention (legal, financial, data) 


10.4.1.1 Parsing 


10.4.1.2 Name, role, value 


10.4.1.3 Status messages 


HA a sw] Ol] uy] ulu 


10.5 Caption positioning 


TT 


10.6 Audio description timing 


11.1.1.1.1 non-text content (open functionality) 


11.1.1.1.2 non-text content (closed functionality 


ala 


11.1.2.1.1 Audio-only and video-only (pre-recorded - open functionality) 


uUlulula 
| 


11.1.2.1.2.1 Pre-recorded audio-only (closed functionality) 


uUlulala 


11.1.2.1.2.2 Pre-recorded video-only (closed functionality) 


11.1.2.2 Captions (pre-recorded) 


11.1.2.3.1 Audio description or media alternative (pre-recorded - open 
functionality) 


refi poli falaia] alala] 


NININININININ! NIN] 


NINININ|IN 


11.1.2.3.2 Audio description or media alternative (pre-recorded - closed 
functionality) 


n 


11.1.2.4 Captions (live) 


11.1.2.5 Audio description (pre-recorded) 


11.1.3.1.1 Info and relationships (open functionality) 


11.1.3.1.2 Info and relationships (closed functionality) 


11.1.3.2.1 Meaningful sequence (open functionality) 


11.1.3.2.2 Meaningful sequence (closed functionality) 


TS a Ul, 


ulalalula 
| 
| 


NININININ|I|N 
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Table 4 ( Continued) 


Requirements 


4.2.2 4.2.3 4.2.4 


4.2.5 


4.2.6 


4.2.11 


4.2.12 


11.1.3.3 Sensory characteristics 


11.1.3.4 Orientation 


11.1.3.5.1 Identify input purpose (open functionality) 


11.1.3.5.2 Identify input purpose (closed functionality) 


11.1.4.1 Use of colour 


11.1.4.2 Audio control 


11.1.4.3 Contrast (minimum) 


11.1.4.4.1 Resize text (open functionality) 


11.1.4.4.2 Resize text (closed functionality) 


11.1.4.5.1 Images of text (open functionality) 


11.1.4.5.2 Images of text (closed functionality) 


11.1.4.10 Reflow 


11.1.4.11 Non-text contrast 


11.1.4.12 Text spacing 


11.1.4.13 Content on hover or focus 


11.2.1.1.1 Keyboard (open functionality) 


11.2.1.1.2 Keyboard (closed functionality) 


11.2.1.2 No keyboard trap 


11.2.1.4.1 Character key shortcuts (open functionality) 


11.2.1.4.2 Character key shortcuts (closed functionality) 


11.2.2.1 Timing adjustable 


11.2.2.2 Pause, stop, hide 


a-a aos ma-d eo eo a ee) 


W/W nI In 


11.2.3.1 Three flashes or below threshold 


11.2.4.3 Focus order 


az 


gz 


11.2.4.4 Link purpose (in context) 


11.2.4.6 Headings and labels 
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Table 4 ( Continued) 


Requirements 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9 4.2.10 4.2.11 4.2.12 
WV LV WPC WH LH WVC LMS LR PST LC PR IL 
11.2.4.7 Focus visible P P > — m S P — — P — — 
11.2.5.1 Pointer gestures P P = P = — 
11.2.5.2 Pointer cancellation — P — — — — P P — P — — 
11.2.5.3.1 Label in name (open functionality) P P = S — — 
11.2.5.3.2 Label in name (closed functionality) P P — S — — 
11.2.5.4 Motion actuation S S = = = = P P = S = = 
11.3.1.1.1 Language of software (open functionality) P S — S S — S 
11.3.1.1.2 Language of software (closed functionality) P S = S — S 
11.3.2.1 On focus P P = = P = = 
11.3.2.2 On input P P — — — — — — P — — 
11.3.3.1.1 Error identification (open functionality) P P — P — S 
11.3.3.1.2 Error Identification (closed functionality) P P P — P — S 
11.3.3.2 Labels or instructions P P S = = P — S 
11.3.3.3 Error suggestion P P — — P — S 
11.3.3.4 Error prevention (legal, financial, data) P P — 2 = = S = = P = P 
11.4.1.1.1 Parsing (open functionality) P S — — S 
11.4.1.1.2 Parsing (closed functionality) — — — — S 
11.4.1.2.1 Name, role, value (open functionality) P P S S 
11.4.1.2.2 Name, role, value (closed functionality) — — — = = 
11.4.1.3.1 Status messages (open functionality) P P P P P P P P P P — P 
11.5.1 Closed functionality — — — — — 
11.5.2.1 Platform accessibility service support for software that provides P P P — — S — — 
a user interface 
11.5.2.2 Platform accessibility service support for assistive technologies P P R = = S = — 
11.5.2.3 Use of accessibility services P P — — = = P = = S — = 
11.5.2.4 Assistive technology P P — — — = P = = S = = 
11.5.2.5 Object information P P — — — — P — — S — — 


1707 : (1 Hed) 708L1 SI 


v9 


Table 4 ( Continued) 


Requirements 


> 
ied 
an 


4.2.4 


4.2.5 


4.2.6 


4.2.11 


4.2.12 


11.5.2.6 Row, column, and headers 


11.5.2.7 Values 
11.5.2.8 Label relationships 


11.5.2.9 Parent-child relationships 


11.5.2.10 Text 


11.5.2.11 List of available actions 


11.5.2.12 Execution of available actions 


11.5.2.13 Tracking of focus and selection attributes 


11.5.2.14 Modification of focus and selection attributes 


11.5.2.15 Change notification 


11.5.2.16 Modifications of states and properties 


11.5.2.17 Modifications of values and text 


NI NININININININ/!NININ|N 


11.6.1 User control of accessibility features 


11.6.2 No disruption of accessibility features 


ac) 


aaki- S eo ee le) 


11.7 User preferences 


11.8.1 Content technology 


11.8.2 Accessible content creation 


11.8.3 Preservation of accessibility information in transformations 


11.8.4 Repair assistance 


11.8.5 Templates 


NININI NIN 


oo ao eo ulu 


NININI NIN 


12.1.1 Accessibility and compatibility features 


12.1.2 Accessible documentation 


12.2.2 Information on accessibility and compatibility features 


Ul ew eee ul ee oe ee (| SS ul ul S v( ul ul ul ul ul ulu 


Ul) ululuUl ula) le ol a) 


Ulu ene eo ulu 


12.2.3 Effective communication 


12.2.4 Accessible documentation 


NS IRILILIKILILINISNSILILILINILINALILANILA LIK 


noid eos SS ee a ulu) 


uUlul ml) ul mlm] ul tml] sls 


ulalalulalululu|lululm 


Ulu) o | 
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Table 4 ( Concluded) 


Reguirements 42.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9 4.2.10 42.11 4.2.12 

WV LV WPC WH LH WVC LMS LR PST LC PR IL 
13.1.2 Text relay services — = = P P P S — P 
13.1.3 Sign relay services — — = P P P S 
13.1.4 Lip-reading relay services — — — P P P S 
13.1.5 Captioned telephony services P P P S 
13.1.6 Speech to speech relay services — — — — P — P 
13.2 Access to relay services P P P S — S 
13.3 Access to emergency services — = — P P P S — P 
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B-2 INTERPRETATION OF TABLE 4 


B.2.0 General 


Table 4 illustrates the impact a specific accessibility 
issue might have on different users. It does this by 
mapping the requirements in this standard with the 


functional performance statements in 4. A requirement 
can be Primary (P) or Secondary (S). 

The technical requirements are listed in a vertical 
column and the functional performance statements 
horizontally. 


The table indicates which functional performance 
statements, and corresponding user needs, are covered 
by each requirement. 


B-2.1 Example 


Reci : 421 422 423 |424 
ee one wv LV WPC WH 
5.1.3.11 

P s ö 2 


Private listening volume 


B-2.1.1 Step 1 


For requirement 5.1.3.11, which relates to the possibility 
of changing the volume when the user is listening in a 
private headset, the table can be read like this: 


425 426 427 428 429 4210 4.2.11 
LH wvc LMS LR PST LC P 
S - - - - S S 


The requirement for private listening volume has a “P” 
for primary support in the column “WV”, which stands 


Requirements 


SITST 
Private listening volume 


This means that private listening volume supports 
the functional performance statements for users who 
cannot see. In other words, the possibility for the user 
to control the volume when listening via a private 
headset is necessary for blind users. 


4.2.2 
Requirements LV 
5.1.3.1 
S 


Private listening volume 


, 


for “without vision”. 


B-2.1.2 Step 2 


The third column shows that, for users with low vision, 
the possibility to control the volume when listening via 
a private headset is not as necessary as for blind users, 
it has an S for Secondary, where the first column had a 
P for Primary. 
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Secondary support means that some users in this group 
may use the accessibility feature in specific situations. 


Reguirements 


5:1.3.10 
Private listening volume 


The fourth column considers users who are colour 
blind; the reguirement on private listening volume is 
not marked at all. Of course, the possibility of changing 
the volume when listening in private headset is nice to 
have for all users, no matter their ability to distinguish 
between colours, but the listening volume does not 
compensate for the colour blindness. 


= 4.2.1 
Requirements wv 
b.1.3.11 

P 


Private listening volume 


Some users who can see, but not weli, need or prefer to 
use audio as an alternative way to use the interface. If 
this alternative is audio via private headset, some low 


Reguirements m 
eg LV 
§:1.3.11 

S 


Private listening volume 
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B-2.1.3 Step 3 


In this way it is possible to assess the impact on 
functional performance statements if a particular 
requirement is not met. 


B-.2.1.4 Step 4 
The table can also be read the other way around: 


Since blind users cannot see the screen, they need an 
alternative way to use the interface. If this alternative 
is audio via private headset, blind users need the 
possibility to change the volume. 


vision users will benefit from the possibility to change 
the volume. 
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ANNEX C 


void 
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ANNEX D 


( Informative ) 
( Foreword ) 


FURTHER RESOURCES FOR COGNITIVE ACCESSIBILITY 


It is evident that people with limited cognitive, language 
and learning abilities have diverse accessibility needs 
and preferences and that there is a need for further 
guidelines and standards. Research in this area is 
ongoing. 

Relevant standardisation work is currently being 
undertaken by the W3C Web Accessibility Initiative 


(WAI). WAI are working to improve the requirements 
and technical guidance for developers, to better address 
Web accessibility for people with limited cognitive, 
language and learning abilities. Current W3C activity 
in this area can be found at https://www.w3.org/WAI/ 
cognitive/. 


ANNEXE 


( Informative ) 
( Foreword ) 
GUIDANCE FOR USERS OF THIS STANDARD 


E-1 INTRODUCTION 


This explanatory annex is designed to enable 
developers, industry, end users, procurement agencies — 
public and private, testing and certifying agencies to 
understand the scope and context of the standard and 
make best use of it. 


This standard contains a wide range of requirements to 
cover a variety of ICT products, services and solutions. 
There are requirements on functional, physical and 
software characteristics. For example, it is necessary 
to understand which requirements are relevant for a 
specific product or service in a specific situation or 
context. 


In a way, this standard is an efficient and consistent 
aggregator of functional performance statements to 
reflect the needs of people with different disabilities 
using ICT; and technical requirements that state how 
different components of ICT ecosystem — telecom, 
hardware, software, web, non-web, documents and 
other such, have to meet these. Many individual 
parts may have been covered in various standards or 
addressed in different forums. This standard does not 
aim to contradict any of them but to provide an up-to- 
date single point source for accessibility requirements 
as far as ICT is concerned. 


The extensive cross-referencing to International and 
Indian standards, guidelines, rules, policies etc. given 
in this standard aims to harmonize all of them and is 
consistent with W3C/WAI/WCAG 2.1 and EN 301 549 
V3.2.1. 


Those who adhere to any of the existing or upcoming 
International and Indian standards can easily relate 
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to this standard. If they need further guidance and 
have suggestions on how to ensure compliance to this 
standard may refer to the Part 2 of this standard dealing 
with Determination of Conformance. 


As will be seen in Part 2 of this standard, testing for 
accessibility requirements does not always result in a 
yes or no. It is important to understand the requirements 
and alternatives available for different end-users. All 
these issues will be further elaborated in Part 2. 


E-2 OVERVIEW 


This Standard consists of thirteen sections (equivalent 
to chapters in a book) and five annexures. 


Clauses 0 to 3 contain background information, scope 
of the standard, references, definitions of terminology 
and explanations of abbreviations. These clauses have 
a lot of valuable information, but it can be hard to read 
the standard from A to Z. 


Clause 4 covers functional performance statements, 
which are directly related to end-user needs. The clause 
explains what functionality is needed to enable end users 
to locate, identify and operate functions in technology, 
no matter their abilities. This is an important section 
where you can learn about what challenges accessibility 
requirements aim to solve. 


Clauses 5 to 13 are the actual technical requirements. 
Most readers start here, but clause 4 can possibly be a 
better place to begin, to really understand how to use 
the detailed technical parts. 


The technical requirements cover many different kinds 
of ICT divided into separate sections, but it is always a 
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good idea to have a look at clause 5, since this is where 
the general requirements are. 


Clauses 9, 10 and 11 are the ones that are most relevant 
to IT software industry and IT use in government, offices 
and homes — they cover web, non-web documents and 
software, including mobile and web apps. 


Annex B describes how the functional performance 
statements of clause 4 relate to the technical 
requirements in clauses 5 to 13. This is a useful tool 
that will, for example, help you to use the standard in 
finalizing requirements at the time of procurement to 
identify the impact that specific requirements have on 
end users when comparing proposals. 


Annex D provides a link to further resources for 
cognitive accessibility. 


E-3 CLAUSE 4 


Clause 4 is in a sense the heart of the standard. The 
end users, with their different needs, are the reason 
accessibility matters. The user needs behind each 
functional performance statement are also the reason 
for each of the requirements in this standard. 


Clause 4 does not include any requirements in itself, 
just descriptions. This may make it seem less important 
but, in reality, it is the other way around. The aim of 
the whole standard is to ensure that end users with 
the varying abilities described in this clause can use 
products and services. 


In this clause, eleven functional performance statements 
based on variations of impairments are described, 
plus privacy and support for Indian languages. 
The impairments can be permanent, temporary or 
situational. End users with multiple impairments 
might need specific combinations of accessibility 
solutions. Therefore, it is necessary to consider all 
different functional performance statements as well as 
a combination of them. 


The concept behind the standard is to let technology 
help compensate the challenges that end users can have. 
The end user can look at accessibility as alternative 
ways to use technology. For example: if the end user 
cannot see, technology can provide sound. If the end 
user cannot hear, the technology can provide text. This 
is what clause 4 is describing for each user group, in 
detail. 


Clause 4 help the used with a better understanding of 
the logic of the requirements in the standard. 


E-4 HOW TO USE THE STANDARD 


E-4.1 Self Scoping Requirements 


The requirements in the present standard are called 
self-scoping. This means that they consist of two parts; 
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the first part is a precondition for the second part, which 
holds the actual requirement. If the first part is true, you 
need to meet the second part of the requirement. If the 
first part is not true, this means that the requirement is 
not applicable. 


For example, a requirement saying “Where ICT 
hardware has speech output, it shall provide [...]” can 
be met in two ways: 


If your product or service provides speech, you need to 
fulfil the second part of the requirement. 


If your product or service does not provide speech, 
you do not need to think about the second part of the 
requirement. The requirement is not applicable. 


To meet the standard means that all applicable 
requirements in the standard are met. 


To get an overview of the requirements in scope of 
your product or service, the user can focus on the 
requirements with the same scoping statements. There 
are online tools that can help you filter out requirements 
that are automatically met. 


E-4.2 Connection between Requirements and 


Functional Performance Statements 


The table in Annex B helps the user to understand the 
connection between the requirements and the functional 
performance statements. There is an instruction on how 
to use the table under B-2. 


Before making a decision about the most suitable 
solution, you also need to think about the context. Here 
are some examples: 


a) In what situation is the solution going to be used? 


b) Which failed requirements are possible to compensate 
with other alternatives, like for example a service desk? 


c) What would it cost to solve an issue with an 
alternative like that? 


d) Will the failed requirements be possible to fix in the 
next version of the solution? 


Suppliers may show how their product or service 
addresses the functional performance statements in 
clause 4 in addition to meeting the requirements in 5 to 
13. This can help you choose which product or service 
is most suitable. 


E-5 VOID 


E-6 ANNEX D: FURTHER RESOURCES FOR 
COGNITIVE ACCESSIBILITY 


Annex D provides a link to W3C resources that 
can be used as guidance to improve the inclusion of 
accessibility for people with limited cognitive, language 
and learning abilities when using ICT products and 
services. 
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ANNEX F 
( Foreword ) 
COMMITTEE COMPOSITION 
Active Assisted Living Sectional Committee, LITD 35 


Organization 


In Personal Capacity 
In Personal Capacity 


Centre for Accessibility in Built Environment 
Foundation, New Delhi 


Centre for Development of Advanced Computing, 
Pune 


ERNET India, New Delhi 
G3ict 


Kannur University, Department of Information 
Technology, Kannur 


Price water house Coopers Private Limited, 
Gurugram 


Seconded European Standardization Expert for 
India (SESEI), New Delhi 


Secure Meters Limited, Gurugram 


Standardization Testing and Quality Certification 
(STQC) 


Narnix Technolabs Private Limited, New Delhi 
In Personal Capacity 
In Personal Capacity 
BIS Director General 


Representative(s) 


PROF SUPTENDRANATH SARBADHIKARI (Chairman) 
SHRI SRINIVASAN RAMAKRISHNAN 


SHRI SUBHASH CHANDRA VASHISHTH 


Dr N. SUBRAMANIAN 
Ms LENALI SINGH (Alternate) 


NAVEEN CHOUDHARY 
DR NIRMITA NARASIMHAN 


DR N. S. SREEKANTH 


MR MOHAMMED ASIF IQBAL 
MR N. S. N. Murty (Alternate) 


SHRI DINESH CHAND SHARMA 


SHRI PUNEET KHURANA 
SHRI ANIL MEHTA (Alternate I) 
Ms Asmita Goyat (Alternate II) 


SHRI ANKIT JAIN 
SHRI A. CHAKRAVARTHY (Alternate) 


SHRI KISHOR N. NARANG 
SHRI SOMESHWAR SINGH 


Ms ABHA KHETARPAL 


Ms REENA GARG, SCIENTIST ‘F’ AND HEAD (ELECTRONICS AND IT) 


[ REPRESENTING DIRECTOR GENERAL ( Ex-officio ) | 


Member Secretary 


SHRI BHANU KRISHNADEV P. 
SCIENTIST ‘B’ (ELECTRONICS AND IT), BIS 
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Panel involved in the Finalization-LITD 35/P1 Accessibility Standards for ICT Products and Services 


Organization 


Centre for Development of Advanced Computing, 
Pune 


Barrier Break Solutions Private Limited, Mumbai 


Centre for Development of Advanced Computing, 
Pune 


DAISY Consortium, New Delhi 

Deque Software Private Limited, Hyderabad 
G3ict 

Indian Institute of Technology Roorkee, Roorkee 


Manufacturers Association for Information 
Technology, New Delhi 


Price water house Coopers Private Limited, 
Gurugram 


Seconded European Standardization Expert for India 
(SESEI), New Delhi 


Standardization Testing and Quality Certification 
(STQC) 


Tata Consultancy Services Limited, Mumbai 


In Personal Capacity 


Representative(s) 
Dr N. SUBRAMANIAN (Convener) 


Ms SHILPI KAPOOR 
Ms LENALI SINGH 


MR DIPENDRA MANOCHA 
Ms SATYA JAYA APARNA PASI 
DR NIRMITA NARASIMHAN 
PROF GAURAV RAHEJA 


MR GEORGE PAUL 
MR RISHI VERMA (Alternate 1) 
Ms NIKHILA SALAKA (Alternate II) 


MOHAMMED ASIF IQBAL 
SHRI DINESH CHAND SHARMA 


SHRI ANKIT JAIN 


CHARUDATTA JADHAV 


SRINIVASAN RAMAKRISHNAN 
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AMENDMENT NO. 1 AUGUST 2022 
TO 


IS 17802 (PART 1) : 2021 ACCESSSIBILITY FOR ICT PRODUCTS AND SERVICES 
PART 1 REQUIREMENTS 


The purpose of this Amendment is to align the clause numbers and Titles of IS17802 (Part 1) with European 
Standard ‘EN 301 549-Accessibility for ICT Products and Services’ for ease of reference. 


(Page 25) — Substitute ‘8.3.4.3.2 Forward approach’ for ‘8.3.4.4 Forward approach’. 

(Page 25) — Substitute ‘8.3.4.3.3 Parallel approach’ for ‘8.3.4.5 Parallel approach’. 

(Page 36, clause 10.3.1.1) — Substitute ‘10.3.1.1 Language of page’ for ‘10.3.1.1 Language of document’. 
(Page 40) — Substitute ‘11.1.3.3 Sensory characteristics’ for ‘11.1.3.2.3 Sensory characteristics’. 

(Page 40) — Substitute ‘11.1.3.4 Orientation’ for ‘11.1.3.2.4 Orientation’. 

(Page 40) — Substitute ‘11.1.3.5 Identify input purpose’ for ‘11.1.3.2.5 Identify input purpose’. 


(Page 40) — Substitute ‘11.1.3.5.1 Identify input purpose (open functionality)’ for ‘11.1.3.2.5.1 Identify 
input purpose (open functionality)’. 


(Page 40) — Substitute ‘11.1.3.5.2 Identify input purpose (closed functionality)’ for “11.1.3.2.5.2 Identify 
input purpose (closed functionality)’. 


(Page 41) — Substitute ‘11.2.1.2 No keyboard trap’ for “11.2.1.1.3 No keyboard trap’. 
(Page 42) — Substitute ‘11.2.1.3 Void’ for ‘11.2.1.1.4 Void’. 
(Page 42) — Substitute ‘11.2.1.4 Character key shortcuts’ for ‘11.2.1.1.5 Character key shortcuts’. 


(Page 42) — Substitute ‘11.2.1.4.1 Character key shortcuts (open functionality)’ for 11.2.1.1.5.1 
Character key shortcuts (open functionality)’. 


(Page 42) — Substitute ‘11.2.1.4.2 Character key shortcuts (Closed functionality)’ for ‘11.2.1.1.5.2 
Character key shortcuts (closed functionality)’. 


(Page 49) — Substitute ‘11.8.0 General (Informative)’ for ‘11.8.1 General (Informative)’. 
(Page 49) — Substitute ‘11.8.1 Content Technology’ for ‘11.8.2 Content Technology’. 
(Page 49) — Substitute ‘11.8.2 Accessible Content Creation’ for ‘11.8.3 Accessible Content Creation’. 


(Page 49) — Substitute ‘11.8.3 Preservation of Accessibility Information in Transformations’ for ‘11.8.4 
Preservation of Accessibility Information in Transformations’ . 


(Page 49) — Substitute ‘11.8.4 Repair Assistance’ for ‘11.8.5 Repair Assistance’. 


(Page 49) — Substitute ‘11.8.5 Templates’ for ‘11.8.6 Templates’. 


(LITD 35) 
Publication Unit, BIS, New Delhi, India 


